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CHAPTER  I 


INTRODUCTION 

As  the  turn  of  the  century  rapidly  approaches ,  the 
influence  of  computers  on  the  private,  business,  and  govern¬ 
ment  sectors  has  never  been  more  evident.  Whether  maintain¬ 
ing  the  family  monthly  budget  in  the  home  or  the  huge  payroll 
in  the  military  pay  system,  the  financial  systems  application 
of  Automatic  Data  Processing  (ADP)  is  merely  one  of  the  many 
uses  of  the  computer.  Virtually  every  aspect  of  daily  life 
is  affected  by  the  conputer,  and  no  where  has  the  inpact  been 
more  evident  than  in  the  Army. 

The  early  data  processing  capabilities  within  the  Army 
were  limited  to  manual  methods  for  business-type  applications 
such  as  financial,  logistical  and  personnel  record  keeping. 
Although  the  first  computers  were  used  for  scientific  purposes, 
it  was  recognized  early  in  their  development  that  electronic 
computing  devices  would  be  an  economical  means  of  processing 
large  volumes  of  data  for  the  peacetime  Army.  Initially,  ADP 
support  focused  on  providing  automation  to  the  installation 
level  with  the  Base  Operations  (BASOPS)  environment  rather 
than  to  tactical  units.  Because  of  the  large  physical  size 
of  the  first  and  second-generation  Automatic  Data  Processing 
Equipment  (ADPE) ,  the  installation  of  computers  in  military 
vans  for  use  at  tactical  unit  level  was  generally  not 


practical.  Their  large  size  and  limited  mobility  necessitated 
that  they  be  installed  in  a  specific  location  and  seldom,  if 
ever,  moved.  Therefore,  the  majority  of  information  and  report 
processing  was  limited  to  manual  means  in  tactical  units.* 

As  technology  imp roved,  the  vacuum  tube  was  replaced 
by  the  transistor  and  computers  became  readily  programable 
through  software  changes  rather  than  the  physical  rewiring  of 
the  Central  Processing  Unit  (CPU) .  These  improvements  led  to 
the  development  of  computer  systems  with  considerably  reduced 
physical  dimensions.  The  reduced  size  of  the  AD PE  provided 
the  opportunity  to  install  computer  hardware  in  van  mounted 
configurations  for  the  mobile  tactical  users.  The  systems 
could  then  be  introduced  to  corps  and  division  level  units  to 
process  the  business-type  information  being  accomplished  in 
the  BASOPS  environment.  These  systems  were  the  onset  of  a 
substantial  automated  information  processing  capability  for 
tactical  as  well  as  garrison  installation  units. 

The  unrelenting  technological  improvements  have  not 
only  increased  the  processing  capabilities  of  the  computer, 
but  have  also  continued  to  reduce  its  size.  With  the  advent 
of  the  micro-chip ,  mini-  and  micro-computers  are  being  devel¬ 
oped  with  virtually  the  same  processing  capability  as  the 

♦There  actually  were  some  early  computer  systems  installed 
in  military  vans  for  use  by  tactical  units.  For  example,  the 
NCR  500  system  was  installed  in  a  two  van  configuration  for 
the  direct  support  unit/general  support  unit  (DSU/GSU)  logis¬ 
tics  supply  system.  They  were,  however,  seldom  if  ever  moved. 
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larger  models.  These  newer  more  compact  models  have  made  poss¬ 
ible  the  development  of  a  number  of  extremely  rugged  and  com¬ 
pletely  portable  computer  systems.  The  new  AD PE  is  being 
adopted  by  the  military  to  meet  the  ever  increasing  demand  for 
ADP  capabilities  in  the  modern  battlefield  of  the  1980s  and 
beyond . 

The  Military  Computer  Family  (MCF)  project  is  underway 
to  develop  standard  tactical  computer  hardware  for  universal 
applications  by  the  Army.  Also  in  development  and  separate 
from  the  MCF  project  are  the  Tactical  Computer  Terminal  (TCT) 
and  Tactical  Computer  System  (TCS) .  The  TCT  and  TCS  currently 
in  development,  with  a  limited  number  of  prototypes  in  the 
field,  are  fully  militarized  micro-  and  mini-computers  respec¬ 
tively.  They  are  designed  to  facilitate  the  real-time  flow 
of  vital  information  for  command  control  operations  by  the 
commander  and  his  staff  on  the  battlefield.  Both  of  the  com¬ 
puters  are  completely  portable  and  ruggedized  for  ease  of 
mobility  with  high  reliability  in  a  tactical  environment. 
Several  applications  systems  are  in  development  for  use  with 
them. 

Along  with  the  new  TCT  and  TCS  for  the  command  and 
control  systems,  new  ADPE  has  been  developed  for  the  informa¬ 
tion  systems  used  in  the  logistical,  financial  and  personnel 
area  of  combat  service  support.  Mini-computer  systems  such 
as  the  Decentralized  Automated  Service  Support  System  (DAS3) 
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are  being  fielded  in  mobil  tactical  configurations  to  replace 
antiquated  equipment  in  divisional  and  non-divisional  units. 
With  this  rapid  proliferation  of  computers  on  the  battlefield, 
and  the  increased  reliance  on  them  for  command  and  control 
and  logistics  support,  timely  software  support  to  keep  the 
systems  operational  has  become  critical. 

Software  support  will  be  required  for  a  variety  of 
reasons.  With  any  computer  system,  whether  it  is  in  the 
development  or  maintenance  phase  of  its  life  cycle,  it  is 
necessary  to  continually  monitor  and,  if  required,  make  mod¬ 
ifications  to  the  software.  Software  changes  could  be  required 
for  the  operating  and/or  applications  system  programs. 

Requests  for  program  changes  may  be  initiated  by  the  system 
developer  or  the  user  in  the  form  of  an  Engineering  Change 
Proposal  (ECP) .  However,  regardless  of  who  initiates  the  ECP, 
ther_  rs  the  possibility  that  a  change  will  introduce  a  new 
problem  to  the  system.  Even  without  change,  a  "bug"  in  the 
system  could  be  discovered  at  any  time  during  the  life  cycle. 

A  problem  in  the  software  can  render  a  computer  useless  or, 
even  worse,  provide  erroneous  information  to  the  commander  on 
the  battlefield.  Therefore,  with  the  increasing  dependency 
on  computers  to  fight  and  win  on  the  battlefield,  it  is  criti¬ 
cal  that  software  changes  be  delivered  expeditiously  to  field 
commands.  The  procedures  for  the  rapid  distribution  of  urgent 
software  changes  to  the  computers  operating  in  divisional  and 


non-divisional  tactical  units  in  the  OCONUS  (Outside  Conti¬ 
nental  United  States)  Theaters  is  the  focus  of  this  study. 

Production  and  distribution  procedures  now  employed 
by  the  various  software  support  and/or  system  design  centers 
are  inadequate  to  provide  software  changes  either  quickly  or 
efficiently.  Time  delays  of  a  few  days  to  several  weeks  are 
the  norm  for  the  delivery  of  changes  to  Europe  or  the  Pacific 
region  from  one  of  the  CONUS  based  design  centers.  The  dif¬ 
ference  in  time  is  dependent  on  the  perceived  urgency  by  the 
agency  involved  since  each  has  its  own  procedure  which  is  often 
dependent  on  which  project  is  "hot"  at  the  time.  The  delay 
may  be  perceived  to  be  tolerable  for  the  service  support  sys¬ 
tems,  or  even  for  command  and  control  systems  during  peace¬ 
time;  however,  the  failure  to  resolve  these  problems  today 
during  peacetime  could  ultimately  lead  to  failure  on  the 
battlefield. 

The  purpose  of  this  study  is  to  investigate  the  feasi¬ 
bility  of  developing  a  standard  means  for  the  rapid  distribu¬ 
tion  of  urgent  software  changes  to  all  divisional  and  non- 
divisional  computer  systems  in  tactical  units  located  in 
OCONUS  Theaters.  The  development  and  subsequent  adherence  to 
standard  procedures  should  ultimately  minimize  the  degradation 
of  command  and  control  due  to  software  failures.  The  study 
was  conducted  by  investigating  various  sources. 

1.  Current  Department  of  the  Army  Regulations,  plans. 
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studies,  and  other  published  documents  concerning  software 
support  for  the  Army. 

2.  Recent  articles  in  military  and  civilian  periodi¬ 
cals  and  journals. 

3.  A  software  support  questionnaire  provided  to  the 
various  Army  design  centers  to  determine  their  distribution 
procedures  in  effect. 

4.  The  above  questionnaire  also  provided  to  Depart¬ 
ment  of  the  Navy  agencies  responsible  for  the  distribution  of 
software  changes  to  the  Atlantic  and  Pacific  Fleets. 

5.  Interviews  with  personnel  at  the  Project  Manager 
(PM)  level  who  are  involved  with  the  software  development  for 
the  TCT  and  TCS. 

6.  Personal  experience  and  knowledge  of  the  author 
while  assigned  to  the  U.S.  Army  Computer  Systems  Command 
(USACSC)  in  various  capacities  from  August  1979  to  June  1982. 

Through  the  use  of  the  sources  listed  above,  the  study 
was  developed  through  the  succeeding  chapters  drawing  final 
conclusions  and  recommendations.  Chapter  II  explores  the  his¬ 
torical  development  of  the  computer?  how  it  has  evolved  in 
the  Army;  and  how  this  untenable  situation  has,  through  years 
of  neglect,  evolved  into  a  major  problem  in  the  military  com¬ 
puter  community. 

Chapter  III  analyzes  the  nature  of  software?  reaffirms 
the  need  for  continued  software  support  throughout  the  system 
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life  cycle;  and  examines  a  questionnaire  designed  to  identify 
the  software  support  problems  being  experienced  throughout  the 
Army.  Analysis  includes  the  dynamic  nature  of  software;  the 
need  for  rapid  software  support;  and  how  the  questionnaire  was 
designed  to  provide  a  comparison  of  present  distribution 
methods  employed  by  the  agencies  involved.  The  questionnaire 
results,  the  means  and  resources  available,  the  distribution 
methods  available,  and  future  requirements  and  capabilities 
will  be  examined  in  Chapter  IV.  The  Automatic  Digital  Network 
(AUTODIN) ,  which  is  currently  used  for  some  data  transmissions 
will  also  be  examined  in  the  chapter  to  determine  the  feasi¬ 
bility  of  electronically  distributing  all  software  changes  to 
divisional  and  non-di visional  users. 

The  final  chapter  draws  conclusions  based  on  the  analy 
sis  of  the  information  gathered  and  recommends  standard  distri 
bution  procedures  for  adoption  Army  wide.  It  should  be  rec¬ 
ognized  that  this  is  an  initial  attempt  to  resolve  a  lingering 
problem,  and  the  examination  is  not  an  all  inclusive  investi¬ 
gation.  Yet,  this  study  may  serve  as  the  catalyst  for  further 
study  to  resolve  this  lingering  and  extremely  serious  problem 
which  faces  the  ADP  developers  and  managers  of  today  and  the 
years  ahead.  If  the  policy  makers  of  the  Army  are  stimulated 
in  the  least  to  further  examine  this  problem,  the  purpose  of 
this  study  will  be  realized. 


CHAPTER  II 


THE  COMPUTER  IN  THE  ARMY 

Prior  to  delving  into  the  current  practices  for  and 
inherent  problems  with  software  maintenance  support,  it  is 
appropriate  to  review  the  development  and  evolution  of  com¬ 
puters  in  the  Army.  The  review  will  encompass  the  evolution¬ 
ary  growth  of  data  processing  systems  from  the  manual  systems 
of  World  War  II  to  the  mini-  and  micro-computers  employed  on 
the  modern  battlefield  of  today.  By  examining  the  "growing 
pains"  experienced  by  the  Army  during  the  development  of 
tactical  computers,  it  will  become  apparent  in  this  chapter 
why  attention  has  only  recently  been  focused  on  timely  soft¬ 
ware  support.  The  impact  of  the  "growing  pains"  on  providing 
adequate  softwa;  e  support  is  summed  up  in  the  findings  of  a 
study  published  in  1980: 

"...project  managers  receive  little  guidance  in 
planning  for  the  software  support  of  systems 
after  deployment  and  have  little  incentive  to 
make  decisions  which  might  be  detrimental  to 
them  individually  but  be  of  significant  over¬ 
all  benefit  to  the  Army."1 

BUSINESS-TYPE  COMPUTER  DEVELOPMENT  IN  THE  ARMY 

The  computer  in  the  Army  had  modest  beginnings.  Prior 
to  World  War  II,  the  Army  consisted  of  a  small  training  force 
of  less  than  200,000  officers  and  enlisted  men.  The  adminis¬ 
tration  of  personnel  files,  medical  files,  financial  accounting, 
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and  logistical  support  was  accomplished  using  primarily  manual 

methods  with  the  aid  of  desk  calculators,  adding  machines, 

2 

addressographs ,  and  other  desk  top  devices.  For  a  small 
force,  these  methods  were  acceptable  with  proven  reliability 
and  a  relatively  timely  output. 

As  the  United  States  drew  closer  to  war,  the  Army 
began  to  rapidly  build-up  its  forces  and  equipment.  The 
administrative  workload  in  the  personnel,  logistics  and  finan¬ 
cial  areas  also  began  to  increase.  By  early  1940,  it  was 
apparent  that  the  manual  administrative  practices  used  so  suc¬ 
cessfully  in  the  past  had  to  be  augmented  with  some  new  method 
of  data  processing.  The  decision  was  made  to  explore  the  pos¬ 
sibility  of  using  punched  card  accounting  machinery  (PCAM)  as 
an  augmentation  to  the  proven  manual  methods.  The  punched 
card  method  eliminated  much  of  the  human  effort  required  in 
manual  or  mechanical  data  processing.  The  PCAM,  or  electric 
accounting  machinery  (EAM)  as  it  was  called,  performed  four 
of  the  six  basic  operations  in  data  processing  -  sorting,  cal¬ 
culating,  summarizing,  and  recording.  Its  quick  adoption 
resulted  in  a  successful  reduction  in  the  administrative  over¬ 
head  generated  by  the  growing  Army.  It  also  facilitated  the 
rapid  completion  of  complex  calculations  which  greatly  expanded 
the  Army's  capabilities  in  business-type  operations.  By  war's 
end,  the  forerunner  of  our  modern  automatic  data  processing 
capability,  the  PCAM,  was  in  use  throughout  the  Army.3 


Although  the  use  of  PCAM  or  EAM  was  a  vast  improvement 
over  the  previous  methods  of  data  processing,  the  drawbacks 
were  many.  In  addition  to  lacking  the  celerity  necessary  to 
process  the  huge  volumes  of  data  generated  on  a  daily  basis, 
it  required  considerable  human  intervention  at  each  step  of 
the  process.  This  intervention  increased  the  manpower  require 
ments  and  introduced  the  possibility  of  human  error  at  each 
step  of  the  data  processing  system.  Even  though  sorting  was 
a  mechanical  process,  each  machine  was  manually  prepared  for 
each  operation.  Punched  cards  -  normally  a  considerable  num¬ 
ber  to  accommodate  the  large  data  volume  -  were  transported 
manually  between  the  various  machines  required  to  complete  a 
given  process.  Operators  were  required  to  wait  during  the 
processing  to  transport  the  cards  to  a  new  location  and  to 
monitor  the  operation  of  the  machine.  Additionally,  a  differ¬ 
ent  machine  was  required  for  each  operation,  necessitating 
the  design  and  programming  of  a  system  for  each  task.  A 
single  electric  computing  device  could  perform  all  these  infor 
mation  functions  automatically  at  speeds  that  were  to  revolu¬ 
tionize  the  data  processing  capability  of  the  world  as  well 
as  the  Army.  More  important,  these  devices  were  to  perform 
tasks  that  were  impossible  for  PCAM  or  EAM  and  they  were 

4 

error  free. 

Although  a  punch  card  machine  was  far  from  being  a 
computer  or  automatic  calculating  machine  as  early  computers 


10 


were  generally  known,  their  use  continued  to  grow  throughout 
the  1950's.  From  1945  through  1956,  the  Army  experienced  a 
series  of  strength  fluctuations  as  a  result  of  shifting  world¬ 
wide  commitments  initially  with  post  World  War  II  peace  and 
then  with  the  Korean  conflict.  Despite  the  fluctuant  manpower 
of  the  Army,  the  growth  in  the  use  of  EAM  remained  steady. 

In  fiscal  year  1951,  EAM  rentals  were  slightly  below  6  million 
dollars.5  By  1956,  the  annual  rentals  had  risen  to  approxi¬ 
mately  8  million  dollars.6  The  punched  card  machines  contin¬ 
ued  to  be  used  into  the  early  1960's,  when  they  were  generally 
replaced  by  commercial-type  computers . 

During  World  War  II,  the  Army  cooperated  with  civilian 
universities  on  several  research  projects  designed  to  develop 
an  automatic  calculating  machine.  While  business-type  data 
processing  was  enhanced  by  the  PCAM,  the  research  focused  on 
new  methods  to  automatically  calculate  huge  volumes  of  data 
for  scientific  and  mathematical  applications  for  both  comner- 
cial  and  military  use.  The  research  proved  to  have  a  deep- 
seated  impact  not  only  on  the  Army,  but  on  the  world  as  well. 
It  led  to  the  development  of  many  of  the  rudiments  of  tech¬ 
nology  which  contribute  to  the  modern  world  of  today.  The 
use  of  the  vacuum  tube  and  electronic  circuitry  in  machinery 
was  the  technological  breakthrough  which  laid  the  foundation 
for  the  development  of  new  automatic  calculating  machines. 
Between  1942  and  1947,  two  engineers  from  the  University  of 
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Pennsylvania,  J.  Presper  Eckert  and  John  W.  Mauchley,  used  the 
new  technology  to  develop  and  construct  what  is  considered  to 
be  the  first  practical  automatic  digital  electronic  computer, 

7 

the  ENIAC  (Electronic  Numerical  Integrator  and  Calculator) . 

In  1947,  the  ENIAC  was  installed  at  the  Ballistics  Research 
Laboratories,  Aberdeen  Proving  Ground,  Maryland,  for  use  in 
the  calculation  of  complex  ballistics  tables  for  the  Army. 

It  proved  to  be  the  fastest  computing  device  developed  up  to 
that  time  with  a  capability  to  perform  5,000  additions  per 

Q 

second  using  the  decimal  system  of  numbers.  It  could  solve 
the  complex  equations  used  in  ballistics  quicker  than  most 
people  could  state  the  problem. 

In  the  scientific  world  of  engineers,  computers  such 
as  ENIAC  and  its  immediate  successors  were  developed  strictly 
for  their  scientific  and  engineering  applications.  Through 
the  first  half  of  the  1950's,  the  computer  was  the  province 
of  the  engineer  and  mathematician  for  scientific  research  and 
analysis.  It  was  not  until  1954  that  a  computer,  the  UNIVAC  I, 
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was  built  specifically  for  business  applications. 

As  the  Army  sought  greater  speed  and  accuracy  in 
acquiring  and  processing  information,  EAM  began  to  be  rapidly 
replaced  by  Automatic  Data  Processing  Systems  (ADPS) .  After 
1956,  there  was  a  significant  increase  in  the  rental  of  com- 
merical,  business  oriented  computers  to  facilitate  the  resource 
management  of  personnel,  finance,  and  logistics  matters  in 


the  Army.  Personnel  and  financial  operations  were  substan¬ 
tially  improved  with  the  ability  to  generate  a  wide  variety 
of  administrative  reports,  which  simplified  and  aided  resource 
management.  ADPS  were  used  in  the  logistics  field  fot  stock 
control,  supply,  and  maintenance  activities,  which  resulted 
in  expeditious  support  and  minimized  inventory  size  with 
decreased  errors.  By  fiscal  year  1960,  ADPS  and  EAM  rentals 
amounted  to  28.8  million  dollars.  However,  the  resulting  bene¬ 
fits  in  both  tangible  and  intangible  savings  counterbalanced 
the  costs  many  times  over.10  The  cost  of  data  processing 
began  to  substantially  decrease  with  the  introduction  of  the 
second-generation  computers . 

The  computers  developed  prior  to  1959  are  referred  to 
as  the  "first-generation  computers".  They  were  characteristic¬ 
ally  large,  bulky  machines  which  used  vacuum  tubes  requiring 
much  air  conditioning  and  relatively  slow  processing  capability 
due  to  the  limited  internal  program  storage  capacity.  The 
computers  used  by  the  Army  in  the  early  1960's  generally  fall 
into  the  category  of  the  "second-generation  computers".  The 
transistor  had  replaced  the  vacuum  tube  enabling  the  manufac¬ 
turers  to  build  the  computers  smaller,  requiring  less  air  con¬ 
ditioning,  and  much  less  expensive.  Computers  developed  after 
1965  are  generally  considered  to  be  "third-generation",  which 
is  when  IBM  introduced  the  System/360  family  of  computers.11 
Even  with  the  introduction  of  mini-  and  micro-computers  in 


the  1970's  and  into  the  1980' s,  the  term  "fourth-generation" 
has  yet  to  be  universally  applied  to  a  new  family  of  computers. 


As  the  1960 's  emerged  with  a  new  generation  of  compu¬ 
ters,  the  business-type  applications  rapidly  expanded' as  the 
cost  effectiveness  of  ADPS  increased  with  the  improved  tech¬ 
nology.  Reduced  processing  time  for  a  large  variety  of  appli¬ 
cations  increased  the  desirability  to  develop  standard  systems 
for  Army  wide  adoption.  It  was  recognized  that  centralized 
management  of  certain  business-type  applications  would  have  a 
major  impact  on  the  conservation  of  appropriated  funds  dedi¬ 
cated  to  the  resource  management  of  personnel,  finance,  and 
logistics  assets. 

One  of  the  first  standard  systems  developed  was  the 
Army  Subordinate  Command  Information  System  (ASMIS) .  The 
system  was  designed  in  1962  for  use  on  a  commercially  avail¬ 
able  RCA  501  computer  with  its  primary  application  the  Active 
Army  Personnel  Reporting  System.  The  system  proved  to  be 
extremely  efficient  in  providing  major  Army  commands  with  per¬ 
sonnel  accounting  data. 

Realizing  the  many  benefits  of  standard  systems,  a 
project  was  begun  in  1965  to  standardize  at  the  installation 
level  Automatic  Data  Processing  Equipment  (ADPE) ,  software 
systems,  and  management  and  reporting  procedures.  The  system 
designed  was  Base  Operations  Information  Systems  (BASOPS) . 
BASOPS  was  designed  for  the  third  generation  IBM  360/30 
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computer  system  with  personnel  accounting,  supply  management,, 
and  financial  management  subsystems.  Through  the  years  since 
its  initial  design,  the  BASOPS  subsystems*  have  undergone 
"enhancement"  programs  to  complement  and  take  advantage  of 
the  improvements  in  hardware  and  software  as  computer  technol¬ 
ogy  rapidly  advanced.  BASOPS  remains  today  as  the  cornerstone 
of  business-type  applications  in  the  Army. 

TACTICAL  COMPUTER  DEVELOPMENT  IN  THE  ARMY 

As  the  evolution  of  the  computer  was  rapidly  advancing 
from  the  one  dimensional  ENIAC  to  the  programable  systems  of 
the  mid  1950's,  there  began  a  significant  effort  to  adapt  com¬ 
puters  to  applications  beneficial  to  the  field  Army  commanders 
Planners  visualized  the  enormous  advantage  commanders  would 
have  if  certain  aspects  of  command  and  control  were  automated 
on  the  battlefield.  The  essentialness  of  ADPS  on  the  modern 
nuclear  battlefield  was  bolstered  by  the  development  of  the 
PENTANA  Army  concept.  The  effort  to  support  the  tactical  ADPS 
concept  began  with  the  formation  of  a  joint  Department  of  the 
Army /Continental  Army  Command  (CONARC)  Committee  to  define  the 
problem,  identify  problem  areas,  and  establish  a  priority  of 

*The  initial  BASOPS  subsystems  were:  MPAS  for  personnal 
accounting,  SMS  for  supply  management,  and  STANFINS  for  finan¬ 
cial  management.  Eventually,  SIDPERS  and  SAILS  replaced  MPAS 
and  SMS  respectively.  Other  subsystems,  such  as  IFS,  MPMIS, 
and  STARCIPS,  were  added  to  BASOPS  over  the  years. 


effort.  The  results  of  the  conmittee  were  published  in 

"Automatic  Data  Processing  System  for  a  Type  Field  Army" 

(February  1957) .  The  major  item  of  significance  emanating 

from  the  committee  findings  was  that  DA  gave  CONARC  the 

responsibility  for  identification  of  operational  requirements 

and  to  develop  technical  requirements  for  an  ADPS  program  for 
1 2 

the  field  Army. 

Under  the  direction  of  CONARC,  one  of  the  earliest 
efforts  to  develop  a  family  of  militarized  computers  for  use 
by  the  field  Army  was  the  FIELDATA  system.  Under  development 
by  the  US  Army  Electronics  Laboratories  at  Fort  Monmouth, 
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New  Jersey,  FIELDATA  proved  to  be  a  project  too  ambitious 
for  the  state-of-the-art  technology  existing  at  the  time. 

The  purpose  of  the  project  was  to  develop  a  militarized  compu¬ 
ter  family  that  could  handle  a  variety  of  applications.  In 
addition  to  using  the  standard  business-type  applications 
associated  with  logistics  and  personnel  and  administrative 
functions,  systems  were  to  be  designed  for  the  automation  of 
intelligence,  operations,  and  fire  support  functions  to  pro¬ 
vide  a  rapid  flow  of  vital  information  to  the  field  commander. 
Many  of  the  problems  associated  with  the  FIELDATA  system 
stemmed  from  its  data  communications  orientation  rather  than 
information  systems.  An  elaborate  plan  to  network  the  system 
components  from  Theater  Army  to  company  level  was  never  realized. 
Though  only  a  few  of  the  applications  conputer  systems 
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were  developed  as  prototypes,  the  FI ELD AT A  project  was  not 
without  its  successes.  It  laid  the  groundwork  for  the  develop¬ 
ment  of  tactical  automatic  data  switches  and  terminals  which 
are  used  throughout  the  Army  today.  Additionally,  standards 
for  the  militarization  of  battlefield  computer  systems  were 
established. 

The  U.S.  Army  Signal  Research  and  Development  Agency 
was  given  the  responsibility  for  engineering  the  hardware  for 
FIELDATA  to  meet  the  following  requirements:  (1)  be  miniatur¬ 
ized  enough  to  be  easily  transported  to  meet  mobility  require¬ 
ments;  (2)  be  able  to  operate  in  extreme  climatic  and  environ¬ 
mental  conditions;  (3)  be  sufficiently  ruggedized  to  resist 
damage  as  a  result  of  movement  over  rough  terrain;  and  (4) 

have  sufficient  processing  capability  to  meet  the  information 
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needs  of  the  field  commander. 

In  response  to  Department  of  the  Army  direction,  in 
August  1960,  CONARC  tasked  the  US  Army  Command  and  General 
Staff  College  to  develop  a  plan  to  automate  field  Army  command 
information  systems.  The  USAC&GSC,  in  coordination  with  var¬ 
ious  other  organizations,  developed  a  plan  which  identified 
five  areas  in  the  command  and  control  framework  as  potential 
candidates  for  automation.  The  plan,  "Command  Control  Infor¬ 
mation  Systems  1970"  (CCIS70) ,  identified  the  candidates  as: 
fire  support,  logistics,  personnel  and  administration,  opera¬ 
tion,  and  intelligence.  The  CCIS70  plan,  after  formal  approval 
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by  DA  on  3  January  1962,  became  the  basic  planning  document 
for  the  automation  of  command  and  control  information  systems 
in  the  field  Army-15 

The  Army  underwent  a  major  reorganization  in  1962 
which  necessitated  the  shift  of  responsibilities  for  the  devel¬ 
opment  of  ADPS  in  the  field  Army  from  CONARC  to  the  U.S.  Army 
Combat  Development  Command  (USACDC)  and  the  U.S.  Army  Materiel 
Command  (USAMC) .  In  1965,  an  effort  to  further  consolidate 
and  centralize  the  various  agencies  and  efforts  involved  in 
the  development  of  tactical  ADPS  was  initiated  with  the  organi¬ 
zation  of  the  Automatic  Data  Field  Systems  Coranand  (ADFSC) 
under  the  control  of  USACDC  as  materiel  developer  and  USAMC 
as  a  combat  developer.  The  first  priority  of  the  new  command 
was  to  assume  the  Project  Manager  (PM)  responsibility  for  the 
development  of  three  of  the  five  original  CCIS70  systems.16 

In  May  1965,  the  Department  of  the  Army  approved  an 
updated  version  of  CCIS70  which  produced  an  implementation 
plan  for  the  development  of  the  Automatic  Data  Systems  within 
the  Army  in  the  Field  (ADSAF) .  The  plan  restructured  the 
original  five  CCIS70  systems  into  three  ADSAF  systems:  Tacti¬ 
cal  Fire  Direction  System  (TACFIRE) ,  Tactical  Operations  System 
(TOS) ,  and  Combat  Service  Support  System  (CS3).17 

Although  all  three  ADSAF  systems  were  identified  as 
conmand  and  control  information  systems ,  real-time  inquiry 
capability  was  being  planned  for  TACFIRE  and  TOS  only.  TACFIRE 
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was  to  provide  automated  fire  support  and  TOS,  current  intel¬ 
ligence  and  operations  data  to  battlefield  commanders.  In 
contrast,  CS3  was  primarily  designed  as  a  batch  processing 
business-type  oriented  system  more  closely  associated  with 
BASOPS  rather  than  command  and  control  functions.  The  sub¬ 
systems  of  CS3  included:  supply  functions,  maintenance  report¬ 
ing  and  and  management,  personnel  and  administration,  and 
medical  accounting  and  reporting.  These  were  not  the  only 
tactical  systems  being  planned  for  development  during  that 
time  period,  but  they  collectively  illustrate  the  difficul¬ 
ties  and  "growing  pains"  the  Army  has  experienced  in  the  tac¬ 
tical  computer  arena. 

In  1969,  the  management  of  ADP  in  the  Army  again  was 

changed  with  the  creation  of  the  U.S.  Army  Computer  Systems 

Command  (USACSC) .  The  new  organization  used  ADFSC  as  its 

nucleus  and  was  given  the  mission  "...to  plan,  direct,  and 

control  all  aspects  of  multicommand  data  systems  development, 

test,  and  installation  and  to  provide  operational  support  to 
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the  commands  using  the  developed  systems."  Thus  the  new 
command  was  given  the  responsibility  of  non-tactical  multicom¬ 
mand  data  systems  as  well  as  those  under  the  ADSAF  program. 

Initially,  USACSC  remained  the  Project  Manager  for  all 
three  ADSAF  systems.  However,  in  late  1970  and  into  1971,  the 
PM  responsibilities  for  TACFIRE  and  TOS  were  transferred  to  a 
newly  established  agency  within  the  Electronics  Command,  the 


19 


Office  of  the  Project  Manager  for  Army  Tactical  Data  Systems 
(PM,  ARTADS) .  ARTADS  assumed  overall  project  management,  how¬ 
ever,  USACSC  maintained  the  responsibility  for  the  software 
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development  for  the  systems.  The  many  problems  this  split 
management  arrangement  caused  were  not  resolved  until  the 
decision  was  finally  made  in  1976  to  reassign  the  tactical 
systems  software  personnel  of  USACSC  to  ARTADS.21 

Of  the  three  ADSAF  systems,  CS3,  which  was  the  only 
system  to  remain  under  the  developmental  control  of  USACSC, 
became  the  first  of  the  three  to  be  fully  fielded  in  1975. 

It  was  designed  for  operation  at  Division  and  Corps  level 
using  commercial  off-the-shelf  third-generation  IBM  360/30 
hardware  installed  in  two  military  vans.  However,  as  is  the 
major  problem  with  all  the  early  business-type  systems  built 
for  the  field  Army,  they  fail  to  adhere  to  the  militarization 
standards  developed  during  the  FI ELD AT A  project.  Generally 
they  are  not  sufficiently  ruggedized  or  miniaturized  to  meet 
the  demand  for  highly  mobile  equipment  on  the  modern  battle¬ 
field.  Although  when  built,  they  met  the  requirement  to  be 
transportable  systems,  the  bulky  dimensions  and  extreme  weight 
of  the  35  foot  vans  significantly  limit  off-road  mobility. 
Additionally,  the  interconnectivity  requirements  of  the  sys¬ 
tems  necessitate  that  they  be  assembled  close  together  in  a 
large  open  area  with  relatively  flat  terrain.  The  time 
required  to  move  the  vans  into  position,  level  them,  and  lay 
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the  interconnecting  cables  makes  setup  a  lengthy  process. 
Consequently,  systems  such  as  CS3  are  normally  left  operating 
in  garrison  when  the  unit  participates  in  field  training  exer¬ 
cises. 

The  remaining  two  ADSAF  systems,  TACFIRE  and  TOS,  took 
divergent  routes.  The  decision  was  made  early  on  in  the  devel¬ 
opment  of  TACFIRE  that  commercially  available  computer  systems 
could  not  meet  the  specifications  required  for  the  system. 
Commercial  use  of  real-time  systems  was  only  in  its  infancy 
with  few  applications,  not  to  mention  the  requirement  to  oper¬ 
ate  in  a  battlefield  environment.  Therefore,  an  extensive 
research  and  development  program  was  necessary  to  design  a 
completely  tactical  real-time  system  with  militarized  hardware 
and  unique  software.  When  considering  the  state-of-the-art 
during  the  early  design  stages  of  the  project,  it  is  under¬ 
standable  why,  not  until  1980,  approximately  15  years  after 
DA  approval  and  more  than  20  years  after  its  inception,  did 
TACFIRE  pass  final  Army  acceptance  for  full  production. 

The  final  ADSAF  system,  TOS,  did  not  realize  the  same 
final  success  as  TACFIRE.  Although  a  European  (7th  Army) 
version  of  TOS  was  tested  in  1969,  the  system  was  never  fielded. 
The  early  developers  chose  to  design  TOS  for  use  on  commer¬ 
cially  available  ADPS  mounted  in  military  vans,  and  they  never 
successfully  overcame  the  problems  associated  with  developing 
real-time  tactical  systems  with  commercial  hardware  and  soft- 


BATTLEFIELD  AUTOMATED  SYSTEMS 

Since  the  early  days  of  the  computer,  when  development 
and  acquisition  of  automated  systems  plodded  along,  rapid  tech¬ 
nological  advancements  have  quickly  led  to  an  ever  increasing 
proliferation  of  computer  systems  on  the  battlefield.  A 
recent  study  identified  a  total  of  299  Battlefield  Automated 
Systems  (BAS)  developed  by  the  Army  which  are  either  presently 

fielded  or  scheduled  to  be  fielded  in  the  various  theaters  by 
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1988.  Recent  projections  demonstrate  that  if  the  prolifera¬ 
tion  continues ,  the  Army  computer  requirements  through  the 

1990  time  period  will  be  250,000  micro-computers  and  29,000 
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mini-computers.  To  combat  the  proliferation,  the  Military 

Computer  Family  (MCF )  project  was  initiated  by  the  U.S.  Army 

Communications  Research  and  Development  Command  (CORADCOM) . 

The  MCF  project  is  intended  to  develop  a  hardware 

design  for  all  embedded  computer  systems  used  throughout  the 

Army.  The  basic  approach  chosen  by  CORADCOM  was  to  develop 

modules  which  can  be  configured  differently  depending  on  the 

intended  application  within  the  Army.  Each  module  performs  a 

defined  function  along  traditional  lines.  There  are  Central 

Processing  Unit  (CPU)  modules,  memory  modules,  power  supply 

modules.  Input  and  Output  (I/O)  interface  modules  and  so  forth 
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to  tailor  a  system  for  its  unique  function. 

On  1  May  1981,  the  U.S.  Army  Communications  and  Elec¬ 
tronics  Materiel  Readiness  Command  and  CORADCOM  merged  to 


form  the  U.S.  Army  Communications-Electronics  Command  (CECOM) . 
In  addition  to  the  MCF  project,  CECOM  inherited  the  responsi¬ 
bility  for  the  research,  development  and  acquisition  of  Army 
command,  control  and  communications  (C3)  systems.  One  of  the 
major  developmental  managerial  responsibilities  of  the  organ¬ 
ization  is  Project  Manager  for  Operations  Tactical  Data  Sys¬ 
tems  (PM,  OPTADS) . 

The  PM,  OPTADS  is  tasked  to  develop  and  acquire  com¬ 
mand  and  control  systems  for  use  by  the  field  commander  and 
his  operations  staff  to  automate  the  flow  of  vital  information 
on  the  battlefield.  The  major  system  currently  under  the  PM 
is  the  Maneuver  Control  System  (MCS) . 

MCS  is  designed  to  provide  overall  operations  control 
from  battalion  through  corps  and  provide  the  commander  with 
real-time  information  from  five  battlefield  control  systems. 
The  systems  from  which  the  information  is  integrated  include 
operations  control,  intelligence  control,  air  defense  control, 
fire  control,  and  admin/log  control.  The  hardware  used  for 
MCS,  in  addition  to  some  items  from  the  MCF,  is  the  AN/UYQ-19 
Tactical  Computer  System  (TCS)  and  the  AN/UYQ-30  Tactical 
Computer  Terminal  (TCT) .  The  TCS,  an  extremely  rugged  and 
transportable  mini-computer  system  especially  developed  for 
the  battlefield  environment,  was  designed  as  a  general  purpose 
system  for  stand-alone  or  subsystem  applications  for  various 
command  and  control  functions.  The  TCT  is  also  fully 
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militarized  and  functions  as  an  intelligent  terminal  utilizing 
three  microprocessors .  Both  the  TCS  and  the  TCT  are  managed 
by  the  PM,  OPTADS,  but  they  are  not  a  part  of  the  MCS  program. 

Although  CECOM  has  the  responsibility  for  the  research, 
development  and  acquisition  of  Army  C3  systems,  all  BAS  are 
not  the  responsibility  of  CECOM.  The  business-type  oriented 
systems,  such  as  CS3,  will  remain  the  responsibility  of  the 
U.S.  Army  Computer  Systems  Command  (USACSC) .  USACSC  has  been 
tasked  to  replace  the  third-generation  van  mounted  IBM  360 
series  computers  and  the  second-generation  National  Cash 
Register  (NCR)  500  DSU/GSU  systems  with  the  Honeywell  Level  6 
mini-computer.  The  Level  6  has  been  installed  in  a  military 
van  to  comprise  the  Decentralized  Automated  Service  Support 
System  (DAS3 ) .  This  van  mounted  ADPS  is  more  rugged  and 
should  prove  to  be  more  mobile  than  the  antiquated  systems  it 
is  replacing. 

The  responsibility  for  the  development  and  acquisition 
of  the  DAS 3  systems  rests  with  the  Program  Manager  for  Tacti¬ 
cal  Management  Information  Systems  (PM,  TACMIS) .  In  1980, 

PM,  TACMIS  initiated  the  fielding  of  the  DAS3  systems  at  the 
non-divisional  maintenance  company  level  for  immediate  replace¬ 
ment  of  the  old  NCR  500  systems.  Processing,  which  took  twelve 
hours  to  complete,  can  now  be  accomplished  in  two.  During  the 
next  five  years,  over  400  DAS 3  will  be  fielded  to  perform  a 
variety  of  personnel,  logistics  and  administrative  functions 
for  commanders  in  the  field. 
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CHAPTER  III 


TACTICAL  COMPUTER  SYSTEM  SOFTWARE  SUPPORT 

For  the  past  thirty  years ,  rapid  technological  advance¬ 
ments  have  enabled  the  Army  to  move  from  the  single  function 
simplicity  of  the  first  electric  computing  machine,  ENIAC ,  to 
the  highly  sophisticated  multifunction  capabilities  of  the 
mini-  and  micro-computers  of  today.  Due  to  its  permanently 
wired  circuitry,  ENIAC 's  processing  capability  was  initially 
limited  to  the  one  function  of  developing  ballistic  tables. 
However,  a  technique  called  "stored  programming"  was  soon 
introduced  which  provided  much  needed  flexibility  to  the  com¬ 
puting  machines.  The  ability  to  provide  a  programmed  set  of 
instructions  for  preplanned  operations,  called  software,  had 
a  major  impact  on  the  evolutionary  development  of  automatic 
data  processing.  As  the  expansion  of  technology  led  to  vast 
improvements  in  computer  hardware  over  the  simplistic  designs 
of  the  early  machines,  new  sophisticated  software  was  developed 
to  instruct  the  computers  to  execute  a  vast  array  of  new  func¬ 
tions.  Thus,  with  no  physical  change  to  the  equipment,  the 
function  to  be  performed  by  the  computer  could  be  easily 
altered  with  the  installation  of  new  software.  It  can,  there¬ 
fore,  be  said  that  if  the  central  processing  unit  (CPU)  is  the 
heart  of  the  computer,1  then  the  software  can  be  categorized 
as  the  brain;  for  software  dictates  the  processes  that  the 


electronic  circuitry  of  the  machine  is  to  accomplish  to  com¬ 
plete  the  intended  task.  And  like  the  brain,  the  full  poten¬ 
tial  of  software  has  yet  to  be  realized. 

NATURE  OF  SOFTWARE 

Computer  software  is  highly  structured  and  is  generally 
considered  in  three  categories:  operating  systems,  utility 
programs  and  applications  systems.  The  operating  system  con¬ 
sists  of  a  set  of  instructions  which,  in  basic  terms,  super¬ 
vises  the  resources  required  to  execute  an  application  or 
utility  program.  It  controls  how  the  computer  functions  during 
a  given  operation.  Utility  programs  are  merely  general  use 
programs  which  can  be  called  upon  to  do  routine,  recurring 
functions.  They  provide  searching  capability,  file  mainten¬ 
ance,  program  compilers  and  assemblers,  computational  subrou¬ 
tines,  and  the  translation  of  program  language  into  machine 
readable  format.  Application  systems  are  a  set  of  programs 
developed  to  perform  specific  functions  for  users.  Where 
operating  systems  and  utility  programs  generally  provide  uni¬ 
versal  capability  across  a  set  of  hardware,  applications  sys¬ 
tems  are  designed  for  processing  a  specific  set  of  data  using 
the  hardware . 

Historically,  computer  software  has  been  written  in 
numerous  programming  languages.  From  the  inception  of  "stored 
programing",  the  instruction  set  directing  the  function  of  the 
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computer  has  been  written  in  many  varying  formats.  Early 
languages  were  little  more  than  basically  digital  instructions 
for  mathematic  and  scientific  calculations.  As  the  number  of 
users  increased,  languages  were  sought  to  improve  the  communi¬ 
cations  capability  between  the  human  and  the  computer.  With 
the  improvement  of  computer  hardware,  indepth  software  research 
led  to  the  development  of  several  levels  of  computer  language. 
The  least  complex  and  simplest  to  use  from  a  programer's  point 
of  view  are  the  high-order  languages  such  as  FORTRAN,  COBOL, 
and  TACPOL .  These  languages  provide  programers  with  a  common 
tool  to  develop  applications  programs  which  are  easy  to  write 
and  easy  to  correct  if  errors  are  detected. 

Assembly  language  is  the  second  level  of  software  used 
to  program  computers.  Considerably  more  complex  than  the  high- 
order  languages,  it  is  used  primarily  in  the  development  of 
operating  systems  rather  than  applications  programs,  and  is  a 
hardware  unique  language.  While  a  language  such  as  COBOL  is 
written  in  relatively  clear  English  text  restricted  by  syntax 
rules,  assembly  is  written  in  a  series  of  discrete,  monolithic 
instructions  in  mnemonic  or  symbolic  form,  which  are  tedious 
to  write  and  even  more  difficult  to  change  should  program  mod- 
ificiations  be  required.  Of  even  greater  concern,  the  diffi¬ 
culty  in  identifying  and  correcting  programing  errors  can 
result  in  critical  delays  in  providing  program  corrections  to 
users  in  the  field.  Also,  with  assembly  language  programs 
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generally  bound  to  a  unique  hardware  system,  it  is  not  readily 
transportable  to  other  hardware  and,  therefore,  costly  to 
develop  and  maintain. 

The  lowest  level  language  is  machine.  Its  instruc¬ 
tions  are  communicated  directly  to  the  electric  circuits  of 
the  CPU  as  a  string  of  on-off  conditions  call  bits.  The  string 
of  bits  -  actually  binary  code  -  controls  the  computer's  pro¬ 
cessing.  All  other  languages  are  converted  to  binary  code 
before  they  can  be  read  by  the  computer. 

When  programs  are  initially  written  in  either  high- 
level  or  assembly  language  codes,  they  are  in  a  nonexecutable 
source  code  format.  In  order  to  be  reduced  to  an  executable 
format  -  a  sequence  of  instructions  which  can  be  understood 
by  the  machine  -  they  must  be  translated  by  either  a  compiler 
for  high-order  languages  or  an  assembler  for  assembly  lang¬ 
uages.  The  translation  process  results  in  the  source  code 
being  reduced  to  a  binary-based  machine  readable  code  which  is 
identified  as  an  object  module.  It  is  the  linking  together  of 
object  modules  into  a  logical  sequence  of  machine  readable 
instructions  that  constitutes  the  nucleus  of  a  software  system. 

SOFTWARE  SUPPORT  REQUIREMENTS 

As  discussed  in  the  previous  chapters,  the  use  of  tac¬ 
tical  computers  at  the  divisional  and  non-divisional  level  is 
on  the  increase.  There  is  a  general  consensus  among  military 
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leaders  that  computers  are  becoming  an  inherent  part  of  command 
and  control  systems.  The  increasing  variety  of  essential  ele¬ 
ments  of  information  required  by  the  commander  to  reach  sound 
decisions  on  the  best  course  of  action  to  initiate,  can  no 
longer  be  processed  rapidly  by  manual  methods.  The  flow  on 
the  battlefield  has  become  so  fluid  that  any  delays  in  receiv¬ 
ing  vital  information  could  result  in  loss  of  life  and/or 
materiel . 

To  meet  the  demands  of  the  commander  to  rapidly  increase 

the  flow  of  information,  new  and  extremely  intricate  computer 

systems  are  being  developed.  With  state-of-the-art  hardware, 

such  as  the  TCT  and  TCS,  now  in  the  Army  inventory,  it  is  the 

development  of  exceedingly  complex  software  for  more  advanced 

applications  of  the  hardware  that  is  consuming  development 

resources.  This  trend,  noted  several  years  ago  in  a  study 

prepared  for  the  Air  Force,  will  continue  in  the  years  ahead: 

"The  software  to  implement  the  various  func¬ 
tions  of  tactical  command  and  control  and  to 
integrate  them  into  an  effective  system  has 
been  difficult  and  costly  to  develop.  Indeed, 
software  is  expected  to  remain  the  critical 
factor  in  tactical  command  and  control  sys¬ 
tems  development."2 

The  increased  reliance  by  commanders  on  computer  sys¬ 
tems  with  exceedingly  complex  software  for  command  and  control, 
has  significantly  increased  the  risks  involved.  Commanders 
must  realize  that  computer  systems  are  subject  to  failures 
that  not  only  can,  but  will,  occur.  The  planning,  directing. 
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and  coordinating  of  tactical  operations  will  be  severely 
limited  until  the  computer  system  is  restored  to  full  opera¬ 
tion  . 

Coping  with  hardware  problems  will  be  relatively  easy 
Diagnostic  test  capability  can  quickly  isolate  the  problem, 
and  defective  modules,  or,  if  required,  computers  will  be 
rapidly  replaced.  Downtime  will  be  easily  minimized. 

The  situation  in  dealing  with  the  intricacies  of  soft 
ware  is  quite  different.  When  a  software  failure  occurs,  th£ 
operators  or  maintenance  personnel  in  the  field  do  not  have 
the  capability  to  resolve  the  problem.  While  a  defective 
hardware  module  can  be  identified  and  physically  replaced  by 
a  repairman,  the  object  modules  which  constitute  a  software 
system  cannot.  System  software  programmers  must  try  to  iden¬ 
tify  which  object  module  is  causing  the  problem,  and  then 
review  hundreds  or  thousands  of  instructions  to  determine 
which  is  in  error.  Once  identified,  the  program  instruction 
at  fault  must  be  corrected  and  a  new  software  system/object 
modules  distributed  to  the  field.  It  is  also  important  to 
note  that  hardware  problems  are  generally  isolated  incidents 
restricted  to  one  piece  of  hardware;  software  problems  are 
not.  If  a  problem  is  detected  on  one  machine,  new  software 
correcting  the  problem  must  be  installed  on  each  computer 
which  operates  with  that  particular  software  system. 

The  sudden  failure  of  software  is  sometimes 
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incomprehensible  to  non- technically  oriented  ADP  users.  While 
there  is  a  general  acceptance  that  any  machine,  whether  mechan¬ 
ical  or  electrical,  will  eventually  experience  some  hardware 
malfunction,  the  feeling  towards  software  is  the  converse. 

Once  a  software  system  has  been  tested  and  fielded  for  univer¬ 
sal  application,  there  is  a  tendency  to  believe  that  the  soft¬ 
ware  cannot  "break".  Unfortunately,  this  misconception  is 
totally  false.  Regardless  of  the  stringent  testing  conditions 
established  for  the  software  during  the  development  phase,  the 
only  real  test  of  the  software  will  be  operation  under  actual 
battlefield  conditions.  And  while  software  will  not  "break" 
in  the  physical  sense,  a  situation  will  inevitably  occur  which 
was  unanticipated  and  went  untested  during  system  development. 
Therefore,  software  malfunctions  should  be  anticipated  for  all 
ADPS.  As  one  author  noted  when  reviewing  the  development  of 
the  TACFIRE  system: 

"The  nature  of  the  software  beast  is  that  a 
zero  defects  level  is  rarely  achieved,  and 
when  claimed,  more  often  than  not  is  indica¬ 
tive  of  inadequate  testing  rather  than  super¬ 
clean  software. "3 

As  more  complex  command  and  control  systems  are  intro¬ 
duced,  the  possibility  of  experiencing  software  failures  increases. 
However,  even  if  the  computer  system  does  operate  as  designed, 
all  may  not  yet  be  well.  Under  conditions  of  large-scale  troop 
deployments  as  in  actual  war,  the  requirements  for  system  input 
and  output  may  be  entirely  different  from  that  envisioned.  The 


sudden  surge  from  the  increased  number  of  users  will  result 
in  unexpected  system  problems. 

Throughout  history,  warring  nations  have  continually 
adapted  to  the  fluidity  of  the  battlefield.  There  is  nothing 
to  suggest  that  the  next  war  will  not  follow  historical  exam¬ 
ple.  Human  decision  making  is  flexible  and  readily  adapts  to 
a  fast  changing  environment?  computer  systems  do  not.  System 
programs  must  be  rapidly  redesigned  and  reinstalled  on  the 
computers  to  meet  the  new  requirement.  Until  the  redesigned 
systems  are  distributed  to  the  field,  the  debilitating  effect 
of  a  major  system  design  flaw  will  be  capability-degrading, 
if  not  catastrophic,  rather  than  providing  the  capability- 
enhancement  for  which  it  was  designed. 

The  realization  that  the  effectiveness  of  the  Battle¬ 
field  Automated  Systems  (BAS)  being  fielded  will  be  dependent 
on  the  efficiency  of  software  support  received  has  led  to  an 
attempt  to  standardize  the  procedures  throughout  the  Army. 

In  July  1978,  DARCOM  (U.S.  Army  Materiel  Development  and 
Readiness  Command)  tasked  CORADCOM  to  develop  a  Post-Deployment 
Software  Support  (PDSS)  plan  with  other  Army  commands  for 
Army-wide  implementation.  A  task  force  was  formed  in  August 
1978  to  investigate  the  problems  of  PDSS  for  battlefield  sys¬ 
tems  that  contained  computers .  The  task  force  was  made  up  of 
representatives  of  Army  staff  agencies.  Army  Commands,  and 
Army  project  managers  to: 
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"...assist  CORADCOM  in  defining  the  PDSS 
problem,  identifying  PDSS  requirements,  form¬ 
ing  assumptions,  and  developing  PDSS  imple¬ 
mentation  alternatives,  evaluation  criteria, 
and  a  selection  methodology."4 

The  major  findings  of  the  task  force  were  not  surpris¬ 
ing.  Numerous  management  and  technical  problems  have  plagued 
the  development  of  adequate  software  support  throughout  the 
years.  Specifically,  the  management  structure  in  the  Army 
has  not  dedicated  the  resources  nor  established  firm  policies 
to  facilitate  the  development  of  a  viable  Army-wide  software 
support  program.  Many  of  the  problems  begin  with  the  develop¬ 
ment  of  the  software  and  are  compounded  during  the  system 
life-cycle.  Uniform  procedures,  guide] ines,  and  standards 
for  all  BAS  in  development  have  not  been  identified.  Specifi¬ 
cally,  in  regard  to  software  development,  the  task  force 
found: 


"In  general,  a  lack  of  concern  during  software 
development  has  produced  BAS  software  with  poor 
maintainability.  The  software  in  Army  BASs  is 
characterized  by  poorly  defined  functional  and 
interface  requirements  and  specifications,  lack 
of  proper  modularization,  too  great  a  use  of 
machine-oriented  languages  (MOLs)  and  inade¬ 
quate  documentation."5 

Another  significant  finding  of  the  task  force  was  that 
there  was  a  continuing  proliferation  of  hardware/software.  As 
previously  discussed  elsewhere  in  this  study,  many  of  the 
hardware  proliferation  problems  will  be  resolved  with  the  use 
of  the  MCF.  The  proliferation  of  software  with  the  myriad  of 
compilers,  assemblers,  subsystems,  utilities,  and  operating 
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systems  will  also  be  partially  resolved  with  the  MCF  as  well 
as  the  TCT  and  TCS.  However,  the  current  problems  caused  by 
the  uniqueness  of  the  assembly  languages  will  take  a  signifi¬ 
cant  amount  of  time  to  overcome.  Software  proliferation  will 
be  a  hindrance  to  effective  software  support  for  years  to  come. 

The  proliferation  of  computer  languages  was  another 
major  problem  identified  during  the  study.  Over  44  different 
computer  languages,  ranging  from  high-order,  assembly,  and 
machine  languages  to  rr.Lcro-process  instructions,  are  in  use 
on  BAS.  The  many  different  languages  increase  the  spectrum 
of  software  support  requirements  from  additional  training  for 
programers  to  the  availability  of  a  large  variety  of  test-bed 
systems.  The  adoption  of  the  DOD  standard  language,  Ada,  for 
use  on  all  Army  BAS  would  be  a  major  step  to  resolve  the  lang¬ 
uage  proliferation  problem.6 

Having  identified  the  major  PDSS  problems,  the  task 
force  turned  towards  the  development  of  a  "software  system 
structure"  to  define  what  elements  of  the  fielded  systems  were 
to  be  supported.  A  work  group  from  the  task  force  defined 
subsystem  elements  of  tactical  software  as:  Operating  System, 
Field  Applications  Software,  Fielded  Field-Training  Software, 
and  Fielded  Hardware  Diagnostic  Software.  The  categories  of 
system  changes  which  would  be  generated  to  provide  software 
support  for  the  subsystems  were:  System  Refinements,  New 
Requirements,  and  Interoperability.7 


The  second  two  categories,  New  Requirements,  which  are 


program  modifications  as  a  result  of  routine  engineering 
change  proposals  (ECP) ,  and  Interoperability  interfaces, 
which  are  changes  that  affect  the  technical  interface  and 
interconnection  of  the  systems,  will  not  require  rapid  distri¬ 
bution  of  software  program  changes  to  the  field.  Those  changes 
will  be  coordinated  with  the  combat  developers  (CD)  and 
released  to  the  field  at  established  intervals,  generally  on 
an  annual  or  semi-annual  basis. 

The  other  category  of  system  changes,  System  Refine¬ 
ments,  encompasses  program  optimization,  technological  improve¬ 
ments,  enhanced  system  performance  and  error  correcting. 

These  changes  are  generally  not  as  a  result  of  major  applica¬ 
tion  or  operating  system  redesign.  Changes  in  this  category, 
which  are  not  required  for  the  immediate  resolution  of  a  major 
malfunction,  are  generally  provided  to  the  field  as  a  new  sys¬ 
tem  version  with  a  number  of  individual  program  changes  nor¬ 
mally  embodied  in  the  new  version  release.  The  number  of 
changes  in  each  release  will  be  dependent  on  the  urgency  and/ 
or  complexity  of  the  changes.  However,  when  urgent  software 
changes  are  required  to  resolve  major  software  problems  which 
have  resulted  in  or  have  the  potential  to  cause  a  system  fail¬ 
ure,  software  modifications  will  be  quickly  made  to  the 
affected  modules  and  they  will  be  expeditiously  distributed 

Q 

to  the  tactical  users  in  the  field. 


Recognizing  that  the  resolution  of  software  problems 
is  "...a  function  of  complexity  of  the  solutions  and  the  pri¬ 
ority  of  the  problems",  the  task  force  established  target  goals 
for  response  time  to  resolve  identified  software  problems.  A 
system  change  would  be  provided  to  the  user  within  24  to  72 
hours  if  the  solution  was  urgently  required  and  not  extremely 
complex  to  resolve.  Those  extremely  complex  problems  would  be 
resolved  "ASAP"  with  immediate  consideration  given  to  a  "patch 
workaround".  Routine  problems  would  be  taken  care  of  from 

Q 

90  to  360  days,  depending  on  the  degree  of  complexity. 

Upon  completion  of  the  task  force  investigation  into 
the  problems  of  and  establishing  the  requirements  for  Army¬ 
wide  PDSS  for  BAS,  a  management  plan  for  PDSS  was  developed 
and  recommended  for  adoption.  To  alleviate  the  management  • 
structure  problems  and  define  specific  software  support 
responsibilities,  the  plan  calls  for  the  establishment  of 
eleven  PDSS  centers*  on  the  basis  of  battlefield  functional 


*The  centers  are  scheduled  for:  (1)  the  U.S.  Army  Arma¬ 
ment  Research  and  Development  Command  (ARRADCOM)  at  Picatinny 
Arsenal,  Dover,  New  Jersey;  (2)  the  U.S.  Army  Communications - 
Electronics  Command  (CECOM)  at  Fort  Monomouth,  New  Jersey; 

(3)  the  CECOM  center  at  Fort  Leavenworth,  Kansas;  (4)  the 
CECOM  center  at  Fort  Sill,  Oklahoma;  (5)  the  U.S.  Army  Compu¬ 
ter  Systems  Command  (USACSC)  at  Fort  Belvoir,  Virginia;  (6) 
the  USACSC  center  at  Fort  Lee,  Virginia;  (7)  the  U.S.  Army 
Missile  Command  (MICOM)  at  Fort  Bliss,  Texas;  (8)  the  U.S. 

Army  Electronics  Research  and  Development  Command  (ERADCOM)  at 
Fort  Monmouth,  New  Jersey;  (9)  the  ERADCOM  center  at  Fort  Hua- 
chuca,  Arizona;  (10)  the  MICOM  center  at  Redstone  Arsenal, 
Huntsville,  Alabama;  and  (11)  the  U.S.  Army  Aviation  Research 
and  Development  Command  (AVRADCOM)  at  Fort  Monmouth,  New  Jersey. 


38 


areas  (BFA) .  Called  the  "hybrid"  approach,  it  provides  for 
the  doctrinal  sensitivity  of  certain  systems  while  insuring 
that  the  technical  complexity  of  the  system  design  is  met. 

PDSS  centers  are  called  for  at  both  TRADOC  centers/schools 
and  the  developing  commands,  as  appropriate.10 

In  addition  to  calling  for  the  establishment  of  the 
PDSS  centers,  other  recommendations  in  the  plan  included  the 
adoption  of  certain  policies  to  improve  PDSS.  Chief  among  the 
recommendations  was  the  reduction  of  the  number  of  different 
types  of  computers  by  designating  the  MCF  as  the  preferred 
hardware  for  use  on  future  systems.  Also,  future  software 
development  would  be  restricted  to  the  use  of  the  Ada  language. 
The  adoption  of  both  of  these  policies  should  significantly 
reduce  the  proliferation  of  hardware/software  and  computer 
languages . 11 

While  an  important  aspect  of  the  PDSS  plan  was  the 
adoption  of  the  "software  system  structure"  and  response  time 
goals  for  system  problems,  the  task  force  failed  to  develop  or 
even  to  identify  the  problems  of  a  distribution  process  for 
software  change  packages  (SCP) .  Of  particular  importance  are 
those  urgently  needed  software  changes  for  the  Operating  Sys¬ 
tem  and  Field  Applications  Software  subsystem  elements  of  the 
BAS  which  must  be  provided  under  wartime  conditions.  Although 
it  can  be  acknowledged  that  major  system  changes  or  enhance¬ 
ments  cannot  be  provided  within  the  response  time  goals  of 
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24  to  72  hours,  the  unanswered  question  remains,  "What  proced¬ 
ure  is  available  for  the  PDSS  centers  to  provide  urgently 
needed  SCP  within  the  established  times  to  the  BAS  users  in 
OCONUS  Theaters?"  The  answer  to  that  question  will  be  pursued 
throughout  the  remainder  of  this  study,  for  the  complexities 
of  the  modern  computer  and  the  incertitude  of  software  can  be 
summed  up  thusly: 

"A  'perfect'  software  system  of  any  magnitude 
with  zero  deficiencies  has  yet  to  be  developed, 
either  in  the  commercial  world  or  within  the 
military.  Much  research  is  ongoing  aimed  at 
formal  proofs  of  software  'correctness'  but 
state-of-the-art  for  the  foreseeable  future 
will  fall  short  of  this  ob jective . " 12 

SOFTWARE  CHANGE  PACKAGE  QUESTIONNAIRE 

Since  the  question  of  how  software  change  packages 
(SCP)  are  to  be  distributed  in  a  timely  manner  to  field  com¬ 
manders  was  left  unanswered  by  the  PDSS  plan,  a  questionnaire 
was  developed  by  the  author  to  examine  the  current  practices 
and  procedures  in  use  by  various  design  centers.  The  ques¬ 
tionnaire  (Appendix)  was  designed  to  be  applicable  to  the 
broad  spectrum  of  software  development  and  design  centers  to 
identify  how  each  produces  and  distributes  SCP  for  the  ADPS 
supported  by  them.  Although  there  is  a  distinct  difference 
between  the  urgency  required  during  war  versus  peacetime,  the 
questionnaire  was  developed  to  determine  what  commonality  or 
extreme  differences  exist  between  the  centers  as  they  operate 
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now  during  peacetime.  Also,  what  positive  procedure  accom¬ 
plished  by  one  may  be  adaptable  to  all. 

The  questionnaire  was  mailed  to  a  total  of  twelve 
organizations.  One  was  sent  to  each  of  the  PDSS  centers  with 
the  exception  of  the  ERADCOM  center  scheduled  for  operation 
at  Fort  Huachuca.  The  center  there  has  yet  to  be  established. 
In  addition  to  the  PDSS  centers ,  the  questionnaire  was  also 
sent  to  the  U.S.  Navy  software  support  activities  for  the 
Atlantic  and  Pacific  Fleets  to  determine  if  they  have  a  pro¬ 
cedure  which  would  be  adaptable  to  the  Army. 

The  criticality  of  providing  timely  software  changes 
to  the  field  commanders  has  been  discussed  in  detail  in  the 
earlier  sections  of  this  chapter.  However,  the  content  and 
the  physical  nature  of  the  SCP  media  has  yet  to  be  expounded. 
Therefore,  before  describing  the  contents  of  the  questionnaire 
in  detail,  the  elements  of  an  SCP  will  be  explained. 

As  elucidated  earlier  in  the  section  entitled  "Nature 
of  Software",  it  is  a  binary  based  machine  readable  code  which 
provides  instructions  to  the  computer.  The  machine  code  is 
divided  into  object  modules  which  when  linked  together  con¬ 
stitutes  the  nucleus  of  a  software  system.  When  an  SCP  is 
developed,  it  will  consist  of  either  an  entire  software  system 
or  merely  one  or  more  object  modules  which  are  only  a  part  of 
a  larger  system.  It  is  important  to  note  that  regardless  of 
the  number  of  object  modules  in  a  given  SCP,  the  data  is 
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represented  by  a  binary  bit  string  that  is  intelligible  only 
to  the  computer.  A  computer  operator  or  repairman  will  be 
unable  to  determine  by  visual  inspection  if  the  SCP  received 
for  installation  has  been  altered  -  obviously  discounted  is 
the  identification  of  physical  defects  to  the  SCP  media,  such 
as  damaged  magnetic  tape.  It  is,  therefore,  critical  that  the 
SCP  be  distributed  to  the  users  completely  free  of  error.  One 
bit  of  data  that  is  incorrect  will  render  the  entire  SCP 
unusable . * 

The  media  used  to  send  software  changes  to  the  field 
are  generally  magnetic  tape  on  open  reels  or  cassettes.  The 
capability  also  exists  for  "floppy  disc"  or  cards  to  be  used 
on  some  systems.  Another  means  to  provide  immediate  software 
changes  to  users  is  through  a  patch  workaround  which  is  pro¬ 
vided  only  in  extreme  emergencies  where  a  catastrophic  failure 
has  occurred.  A  patch  is  a  correction  to  the  machine  language 
instruction  which  must  be  entered  directly  into  the  system 
software.  This  type  of  change  is  extremely  limited  and  should 
only  be  attempted  when  a  software  analyst  is  available  to  make 
the  change.  Therefore,  for  the  purposes  of  this  study  which 
is  limited  to  BAS  which  operate  in  a  field  environment  without 

*An  SCP  can  contain  from  thousands  to  millions  of  bits 
of  data  depending  on  the  number  of  object  modules  being  modi¬ 
fied.  SCP  containing  50  to  60  million  bits  of  information 
are  common . 
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software  analysts  immediately  available,  the  capability  to  use 
patch  workarounds  were  not  explored  in  the  questionnaire. 

In  addition  to  providing  the  obvious  information  deal¬ 
ing  with  the  method  of  distribution,  frequency  and  urgency  of 
the  SCP  as  well  as  the  number  of  systems  supported,  the  ques¬ 
tionnaire  was  designed  to  provide  other  pertinent  information. 
The  organizational  level  that  the  changes  are  sent  to,  for 
example,  is  significant  for  two  reasons.  First,  it  indicates 
the  type  of  outside  support  that  will  generally  be  available 
to  the  user.  That  is,  the  higher  the  organizational  level, 
the  more  support  that  is  generally  available  to  the  unit. 
Secondly,  it  provides  an  excellent  indication  of  the  diffi¬ 
culty  involved  with  providing  distribution  directly  to  the 
unit.  Distribution  of  SCP  to  company  level  divisional  units 
is  considerably  more  difficult  and  complex  than  to  Theater  and 
Corps  units . 

Another  area  of  vital  concern  is  the  expertise  of  the 
personnel  who  operate  the  computers.  If  a  computer  is  oper¬ 
ated  by  the  functional  user  rather  than  a  trained  ADP  operator, 
there  is  a  greater  chance  for  a  problem  to  develop  during  the 
installation  of  the  software  changes.  Also,  software  mainte¬ 
nance  personnel  may  be  required  by  some  organizations  to 
rotate  from  computer  to  computer  installing  software  changes. 
Contractor  personnel  may  also  be  required  to  install  changes 


on  some  systems. 


The  media  used  to  send  changes  to  the  field  are  quite 
significant  since  they  impact  on  the  range  of  options  available 
to  make  distribution.  For  example,  if  it  is  on  floppy  disc  or 
cassette  tape,  the  SCP  cannot  be  transmitted  via  AUTODIN  and 
must,  therefore,  be  mailed  or  sent  with  a  courier.  Also,  the 
media  impact  on  where  and  how  the  reproduction  process  is 
accomplished.  If  an  SCP  is  mailed  to  each  site,  the  resources 
to  copy  the  change  once  for  each  site  must  be  available  at  the 
support  center.  If  transmitted  via  AUTODIN,  only  one  copy, 
regardless  of  the  number  of  sites,  is  required.  (The  aspect 
of  using  AUTODIN  for  the  distribution  of  SCP  will  be  discussed 
further  in  Chapter  IV.) 

The  remainder  of  the  questionnaire  is  devoted  to  the 
type  of  system  supported  (i.e.  developmental  or  fielded);  why 
the  present  plan  is  in  use;  and  the  possible  shortcomings  or 
inadequacies  of  the  system  presently  used.  Any  recommenda¬ 
tions  on  how  the  distribution  of  SCP  could  be  improved  was 
also  solicited. 

The  questionnaire  was  mailed  under  a  cover  letter 
dated  22  January  1982,  to  the  twelve  support  centers  previously 
identified.  The  response  to  the  questionnaire  was  positive 
by  all  the  organizations  involved.  While  the  quality  of  the 
responses  was  good,  the  information  provided  identified  ser¬ 
ious  deficiencies  in  the  timely  distribution  of  SCP. 
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CHAPTER  IV 


THE  SCP  DISTRIBUTION  PROCESS 

The  previous  chapters  of  this  study  were  primarily 
concerned  with  building  a  foundation  on  which  the  reader  could 
develop  an  appreciation  for  the  critical  nature  of  and  the 
potential  problems  associated  with  tactical  computer  system 
software  support.  First,  the  evolution  of  the  computer  was 
described,  and  then  the  snail-like  pace  in  the  development  of 
militarized  computers  for  employment  in  the  tactical  arena  was 
expounded.  The  numerous  delays  in  the  fielding  of  TACFIRE  and 
the  failures  associated  with  TOS  provided  vivid  examples  as  to 
why  the  focus  of  the  Army  has  remained  on  the  development, 
rather  than  the  maintenance,  of  software.  Next,  to  provide  an 
understanding  of  the  criticality  of  timely  software  support, 
the  dynamic,  and  sometimes  fragile  nature  of  software  was 
explained.  And  finally,  after  examining  the  Post-Deployment 
Software  Support  (PDSS)  Plan,  the  questionnaire  sent  to  var¬ 
ious  software  support  agencies  to  determine  the  level  of  soft¬ 
ware  support  currently  available  to  the  field  commanders  was 
described  to  the  reader.  With  the  need  for  timely  software 
support  firmly  established,  the  study  now  shifts  focus  to  the 
means  and  resources  available  to  provide  the  required  software 
support. 

In  this  chapter,  the  questionnaire  responses  will  be 


analyzed  to  compare  the  various  distribution  methods  employed 
by  the  agencies  involved.  Capability  shortfalls  will  be  read¬ 
ily  identifiable  as  the  means  available  to  accommodate  timely 
software  support  are  examined.  Inadequacies  of  current  distri¬ 
bution  methods  will  then  be  evident  when  contrasted  to  the 
means  and  resources  presently  available  to  support  centers. 
Software  support  problems  identified  by  the  support  centers 
will  be  analyzed  to  determine  if  the  Software  Change  Package 
(SCP)  can  be  delivered  in  a  timely  manner  to  commanders  during 
time  of  war.  And  due  to  the  anticipated  increase  in  the  num¬ 
ber  of  Battlefield  Automated  Systems  (BAS)  that  will  be 
employed  in  the  battlefield,  the  future  software  support 
requirements  will  be  identified  to  determine  the  improvement 
in  capability  required  to  accomplish  rapid  SCP  distribution. 
Without  improvements  in  the  SCP  distribution  process,  the 
ability  to  provide  timely  software  support  to  field  commanders 
is  questionable. 

SCP  QUESTIONNAIRE  RESULTS 

Of  the  twelve  SCP  Questionnaires  mailed  to  the  organ¬ 
izations  identified  earlier  in  the  study,  eight  were  completed 
and  returned  to  the  author.  The  eight  received  consisted  of 
two  from  the  Navy  support  agencies  and  six  from  the  Army  PDSS 
centers.  The  other  four  centers*  are  in  their  formative  stages 

♦The  four  PDSS  cen.ers  are:  (1)  the  CECOM  center  at  Fort 
Monmouth;  (2)  the  USACSC  center  at  Fort  Lee;  (3)  the  ARRADCOM 
center  at  Pecatinny  Arsenal;  and  (4)  the  AVRADCOM  center  at 
Fort  Monmouth. 
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of  development  and  are  not  yet  responsible  for  the  distribu¬ 
tion  of  software  changes;  therefore,  limited  information  only 
could  be  provided  based  on  projected  requirements.  The  BAS 
covered  by  the  questionnaires  received  spanned  an  array  of 
Battlefield  Functional  Areas  (BFA) ,  to  include  Fire  Support, 
Intelligence  and  Electronic  Warfare,  Air  Defense,  Combat  Ser¬ 
vice  Support,  and  Maneuver.  With  the  exception  of  one  PDSS 
center,  the  SCP  Questionnaires  were  completed  based  on  fielded, 
rather  than  developmental  systems.*  Rather  than  providing  the 
specifics  on  each  questionnaire  in  this  portion  of  the  study, 
a  general  summary  only  will  be  discussea.  Overall  responses 
to  specific  questions  can  be  reviewed  with  the  annotated  sample 
questionnaire  provided  in  the  Appendix. 

Although  some  of  the  responses  provided  vary  signifi¬ 
cantly,  there  is  a  considerable  degree  of  commonality  among 
the  various  support  centers.  The  dominant  medium  employed  to 
distribute  software  changes  to  the  field  is  magnetic  tape, 
either  on  an  open  reel,  cassette,  or  cartridge.  No  systems 
were  reported  to  use  "floppy"  disc  or  card  media  for  software 
distribution.  The  other  medium  identified  as  being  used  for 
a  number  of  BAS  is  ROM  (Read  Only  Memory) .  ROM  is  embodied  on 
a  microchip,  and  not  as  an  object  module  of  machine  readable 

*The  questionnaire  completed  by  the  CECOM  PDSS  center  at 
Fort  Leavenworth,  Kansas,  was  based  on  the  Maneuver  Control 
System  (MCS)  which  is  currently  in  development.  A  PDSS  Imple¬ 
mentation  Plan  is  being  developed  for  MCS  as  it  is  scheduled 
to  enter  the  deployment  stage  of  its  life-cycle  in  July,  1983. 
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code  stored  in  Random  Access  Memory  (RAM) .  It  is  neither  iden¬ 
tifiable  strictly  as  hardware  or  software  and,  therefore,  nor¬ 
mally  identified  as  "firmware".  As  the  nature  of  "software" 
was  developed  in  Chapter  III,  ROM  as  "firmware"  was  not  dis¬ 
cussed,  nor  was  it  included  on  the  questionnaire.  However, 
while  the  reprogramming  of  non-software  intensive  systems  using 
ROM  firmware  is  not  the  focal  point  of  this  study,  the  impact 
of  ROM  on  the  distribution  of  programming  changes  to  tactical 
computers  cannot  be  totally  ignored.  The  problems  associated 
with  the  distribution  of  ROM  will,  therefore,  be  briefly  dis¬ 
cussed  later  in  this  study. 

The  following  is  a  summary  of  the  responses  to  the 
SCP  Questionnaire: 

1.  For  BAS  distributing  SCP  on  magnetic  tape,  the 
multiple  copies  required  to  provide  one  copy  to  each  system 
are  generally  produced  at  the  CONUS  based  PDSS  centers.  Some 
reproduction  is  accomplished  at  field  sites,  but  normally  only 
for  local  use.  There  are  exceptions,  however,  such  as  when 
specific  operator  training  must  be  conducted  prior  to  the  SCP 
being  applied  to  all  BAS.  In  such  cases,  reproduction  and 
distribution  are  accomplished  in  theater  after  training  is 
completed . 

2.  The  primary  methods  of  distributing  SCP  to  tacti¬ 
cal  units  is  mail;  followed  closely  by  hand  carrying  the 
changes  to  each  BAS  site.  Although  the  majority  of  software 
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changes  are  routine,  and,  therefore,  not  considered  time  sensi¬ 
tive,  a  significant  number  -  approximately  forty  percent  - 
are  in  response  to  time  sensitive  problems  categorized  as 
either  urgent  or  emergency.  Despite  the  time  sensitive  nature 
of  urgent  problems,  the  majority  of  urgent  SCP  are  accorded 
the  same  distribution  priority  as  routine  changes  when  they 
are  mailed  to  users  in  the  field.  There  was  no  indication 
from  any  of  the  responses  that  emergency  SCP  are  every  mailed. 

3.  Emergency  SCP  and  urgent  SCP  that  require  expedi¬ 
tious  delivery  are  normally  hand  carried  to  the  affected  sites. 
SCP  are  also  hand  carried  if  operator  training  is  to  be  con¬ 
ducted  in  conjunction  with  their  loading.  Usually,  Department 
of  Defense  (DOD)  civilians  or  contractor  personnel  from  CONUS 
are  the  technicians  who  have  the  software  knowledge  necessary 
to  hand  carry  and  install  the  software  changes  at  the  computer 
sites.  Few  military  personnel  are  assigned  to  PDSS  centers, 
and  if  assigned,  rarely  are  they  sufficiently  technically 
oriented  to  resolve  software  problems  during  SCP  loads,  and/or 
to  conduct  operator  training  on  the  system  changes  provided  in 
an  SCP.  The  only  agency  to  identify  a  military  courier  as  the 
means  to  distributed  software  changes  was  one  of  the  Navy  sup¬ 
port  centers.  At  that,  it  was  limited  to  18  percent  of  the 
time . 

4.  The  only  significant  user  of  AUTODIN  to  provide 
changes  to  the  field  is  the  U.S.  Army  Computer  Systems  Command 


(USACSC) .  Approximately  fifty  percent  of  their  urgent  soft¬ 
ware  changes  and  virtually  all  of  their  emergency  changes  are 
distributed  by  transmitting  SCP  via  AUTODIN  to  the  field  com¬ 
manders  . 

5.  The  organizational  level  to  which  the  SCP  are  dis¬ 
tributed  is  normally  division  and  lower  with  the  functional 
user  responsible  for  operating  the  computer  rather  than  a 
trained  ADP  operator.  Since  relatively  few  software  mainte¬ 
nance  personnel  are  available  on  site  to  make  the  software 
changes,  the  SCP  are  applied  either  by  the  users  when  received 
by  mail  or  AUTODIN,  or  by  contractor  or  PDSS  center  personnel 
when  they  have  hand  carried  the  software  changes  to  the  site. 

6.  When  queried  as  to  why  each  organization  was  using 
the  procedures  identified,  the  majority  of  the  questionnaire 
responses  specified  quick  delivery,  error-free  transmittal, 
and  Configuration  Management  (CM)  control  as  the  primary 
reasons.  Few  could  identify  any  shortcomings  or  inadequacies 
in  the  system  presently  used  and  many  were  unable  to  provide 
suggested  improvements  in  their  procedures.  Yet,  in  most 
cases,  an  urgent  software  change  could  not  be  distributed  to 
all  required  BAS  in  the  PDSS  study  goal  of  24  to  72  hours. 

7.  Comparisons  of  the  Navy  software  support  agencies 
responses  to  those  of  the  Army  PDSS  centers  presented  little 
contrast  in  procedures.  They  also  mail  or  hand  carry  software 
changes  to  the  ships  at  sea  and  are  in  the  midst  of  studying 
alternative  distribution  methods. 


While  some  information  requested  by  the  questionnaire 
may  have  required  a  written  response,  not  all  of  the  comments 
received  were  deemed  relevant  for  the  purpose  of  this  study, 
and  therefore,  will  not  be  considered  for  inclusion  in  the 
study.  Narrative  statements  that  were  considered  signifi¬ 
cantly  relevant  and/or  required  further  analysis  will  be  dis¬ 
cussed  throughout  the  remainder  of  this  section.  Also  dis¬ 
cussed  will  be  information  or  comments  received  by  the  author 
when  conducting  telephonic  interviews  with  representatives 
from  the  PDSS  centers.  The  interviews  were  conducted  initially 
to  seek  a  clarification  to  some  of  the  written  responses 
received  from  the  organization  contacted.  In  many  instances, 
in  addition  to  receiving  the  clarification  sought,  new  infor¬ 
mation  not  originally  requested  by  the  questionnaire  was  gained 
through  the  course  of  the  conversation. 

One  such  conversation  revealed  a  new  development  in 
the  Fire  Support  BFA.  A  soon  to  be  released  version  of  TACFIRE 
will  have  emergency  patch  capability  for  on  site  problem  reso¬ 
lution.  Although  a  movement  in  the  right  direction,  only  a 
limited  capability  to  make  emergency  software  changes  will  be 
available.  More  complex  and/or  extensive  software  modifica¬ 
tions  will  remain  limited  to  the  PDSS  center  for  distribution 
with  mail  or  hand  delivery. 


Also  revealed  during  the  conversation  was  a  problem 
with  the  delivery  of  cassette  tapes  through  the  mail.  Rough 


handling  in  the  postal  system  can  cause  a  physical  movement 
of  the  magnetic  tape  in  the  cassette.  The  tape  header  infor¬ 
mation  is  then  no  longer  at  the  normal  start  position,  and, 
therefore,  the  SCP  cannot  be  loaded  into  the  computer.  To 
resolve  the  problem,  maintenance  personnel,  if  available  in 
theater,  must  be  contacted  to  reposition  the  tape,  or  an 
entirely  new  tape  must  be  reproduced  from  the  master  and 
resent  to  the  site.  While  thrs  problem  can  be  currently  mini 
mized  with  the  relatively  few  systems  now  in  the  tactical 
arena,  it  will  soon  be  compounded  as  systems  such  as  the 
Battery  Computer  System  are  fielded.  As  the  requirement  to 
mail  cassettes  to  the  battery  and  company  level  increases, 
the  volume  of  SCP  damaged  in  the  mail  will  significantly 
increase. 

Another  area  of  significance  that  was  discussed  with 
personnel  from  several  PDSS  centers  is  the  large  number  of 
BAS  that  will  be  programmed  using  ROM.  Systems  such  as  those 
installed  in  the  M-l  Tank  and  UH-1  Helicopter  as  well  as  many 
other  weapons  systems  will  require  the  rapid  distribution  of 
ROM  for  urgent  or  emergency  programming  changes  for  thousands 
of  computers  in  the  field.  Most  PDSS  centers  envision  the 
distribution  of  the  ROM  being  conducted  using  the  existing 
supply  system  for  repair  parts.  Urgent  problems  may  not 
require  an  immediate  fix  and,  therefore,  could  be  adequately 
resolved  in  this  manner;  however,  emergency  problems  cannot. 


While  emergency  problems  may  be  considered  rare,  an  example 
of  a  problem  with  devistating  consequences  comes  readily  to 
mind.  Emergency  programming  changes  to  a  ROM  in  the  Biologi¬ 
cal  Detector  System  would  be  required  if  a  new  chemical  or 
biological  agent  was  suddenly  introduced  on  the  battlefield. 
Unless  a  programming  change  is  rapidly  distributed,  the  inabil¬ 
ity  of  the  detectors  to  identify  the  new  chemical  and  provide 
an  alarm  for  the  soldiers  in  the  area  would  lead  to  a  serious 
degradation  in  the  fighting  capability  of  the  units  on  the 
battlefield. 

Although  the  SCP  Questionnaire  did  not  provide  any  new 
insights  into  how  to  rapidly  distribute  urgent  and  emergency 
software  changes,  the  responses  reaffirmed  the  need  to  analyze 
existing  methods,  identify  problems,  and  develop  new  proced¬ 
ures  for  adoption  by  PDSS  centers  Army  wide.  In  the  section 
that  follows,  existing  distribution  methods  will  be  analyzed 
to  determine  their  inadequacies,  and  the  shortfalls  of  the 
distribution  means  currently  available  will  be  identified. 

SCP  DISTRIBUTION  METHODS  AND  CAPABILITY  SHORTFALLS 

When  analyzing  the  results  of  the  SCP  Questionnaire, 
it  is  readily  apparent  that  the  majority  of  the  PDSS  centers 
have  entrusted  the  capability  to  rapidly  distribute  software 
changes  to  resolve  BAS  software  problems  to  the  U.S.  Govern¬ 
ment  postal  system.  Admittedly,  most  of  the  SCP  mailed  to 
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users  are  routine,  but  there  are  many  that  are  urgent.  How¬ 
ever,  whether  urgent  or  simply  routine,  it  is  the  failure  to 
deliver  SCP  in  a  timely  manner  that  highlights  the  major  inad¬ 
equacy  of  mailing  changes  to  OCONUS  users. 

The  time  required  for  OCONUS  addressees  to  receive 
mailed  SCP  is  estimated  by  most  centers  to  be  between  15  and 
30  days.  While  this  delay  may  be  tolerable  in  peacetime, 
urgent  problem  resolution  that  is  delayed  during  wartime  may 
have  a  significant  impact  on  the  field  commanders.  Certain 
problems,  categorized  as  urgent  simply  because  a  system  stop¬ 
page  has  not  occurred,  may  have  a  considerable  debilitating 
effect  on  the  field  commander's  capability  to  process  vital 
command  and  control  information  on  the  battlefield.  The  rapid 
resolution  of  this  type  of  urgent  problem  will  consume  the 
aggregate  of  PDSS  center  time  and  personnel  resources.  It  is 
inconceivable  that  such  an  intensive  effort  could  be  allowed 
to  be  negated  by  postal  system  delays  of  two  weeks  or  more. 

Another  negative  aspect  of  mailing  software  changes  is 
the  considerable  drain  on  resources  in  the  preparation  of  the 
packages  for  mailing.  First,  reproducing  a  copy  of  the  SCP 
from  the  master  for  each  computer  requires  a  large  number  of 
blank  tapes.  While  only  a  relatively  few  computers  are  in 
operation  today  for  the  majority  of  the  tactical  systems,  hun¬ 
dreds  and  in  many  cases  thousands  of  computers  will  soon  be 
functioning  on  the  battlefield  with  each  requiring  software 
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support  in  the  form  of  SCP.*  To  meet  the  support  requirements 
the  number  of  copies  of  each  SCP  being  reproduced  will  dramat¬ 
ically  increase.  Therefore,  the  cost  of  acquiring  blank  mag¬ 
netic  tape  will  proportionally  increase.  Also  increasing  will 
be  the  possibility  of  creating  tapes  with  utility  copy  errors. 
Secondly,  to  provide  an  SCP  to  each  site  by  mailing,  the  mag¬ 
netic  tapes,  whether  on  open  reel,  cassette,  or  cartridge, 
must  be  packaged  in  a  container  with  written  instructions, 
labeled  with  addressing  information,  and  transported  to  the 
local  Post  Office  for  mailing.  And  finally,  as  noted  earlier 
with  the  physical  movement  of  the  tape  in  cassettes,  SCP  trans 
mitted  through  the  mail  are  subject  to  damage  or  loss. 

Sending  software  changes  to  OCONUS  Theaters  employing 
the  postal  system  during  time  of  war  is  another  area  of  major 
concern.  While  two  to  four  weeks  is  the  normal  delay  for 
mailed  SCP  in  peacetime,  the  amount  of  delay  that  might  be 
experienced  during  a  major  or  even  limited  conflict  could  be 
extreme.  They  could  easily  be  lost  in  the  "shuffle"  of  mater¬ 
iel  being  delivered  in  Theater  to  support  the  war  effort. 

The  next  most  popular  method  of  delivering  SCP  to  the 
BAS  in  the  tactical  arena  is  by  hand  carrying.  While  this 
method  provides  the  greatest  degree  of  surety  against  damage, 
loss,  or  alteration,  the  inadequacies  of  this  method  are  many. 

*For  example,  current  estimates  show  that  as  many  as 
3,000  TCS/TCT  will  require  support  by  the  year  1990. 
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Again,  as  noted  earlier  with  regard  to  mailing,  there  are 
relatively  few  sites  using  a  particular  BAS  today,  and  hand 
carrying  of  software  changes  to  the  individual  computers  can, 
therefore,  be  readily  accommodated.  However,  as  the  number 
of  sites  increases,  the  resources  required  to  rapidly  deliver 
an  SCP  to  each  computer  location  would  be  exorbitant.  In 
time  of  war,  it  would  be  virtually  impossible.  The  problem 
of  DOD  civilian  or  contractor  personnel,  rather  than  military 
technicians,  delivering  software  changes  in  a  war  zone  is  not 
the  major  obstacle  since  it  has  been  done  in  past  wars.  The 
problem  is  the  mere  volume  of  personnel  necessary  to  hand 
carry  and  install  the  required  number  of  SCP  in  a  timely  man¬ 
ner. 

The  other  major  problem  with  hand  carrying  the  changes 
is,  as  was  illustrated  when  discussing  the  problems  of  mailing 
the  software  changes,  the  huge  amount  of  reproduction  that 
must  be  accomplished  for  each  change.  With  more  than  a  quar¬ 
ter  of  a  million  computers  projected  for  employment  in  the 
Army  by  1990,  the  severe  drain  on  resources  makes  hand  carry¬ 
ing  of  SCP  to  commanders  in  the  field  a  questionable,  if  not 
an  impossible,  solution  to  the  distribution  problem. 

The  problems  associated  with  the  distribution  of  pro¬ 
gramming  changes  to  BAS  computers  that  use  ROM  (Read  Only  Mem¬ 
ory)  chips  are  many.  First,  consideration  must  be  given  to 
how  they  are  produced  for  the  Army  PDSS  centers.  The 
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government  does  not  have  the  capability  to  produce  ROM  chips 
for  the  various  BAS  that  are  currently  in  the  field  or  being 
developed  for  fielding  sometime  in  the  future.  Therefore, 
the  ROM  must  be  produced  by  civilian  contractors  who  have  the 
capability  to  mass  produce  the  required  number  for  the  Army 
systems.  An  obvious  drawback  to  having  civilian  firms  produc¬ 
ing  the  ROM  is  their  inability  to  quickly  "retool"  for  neces¬ 
sary  program  changes .  In  addition  to  the  problem  of  being 
unable  to  make  urgent  programming  changes  in  a  rapid  manner, 
there  is  no  capability  to  make  emergency  changes  using  patches 
applied  by  the  computer  maintenance  personnel,  or  even  opera¬ 
tors.  Both  the  "retooling"  and  emergency  patch  capability 
problems  may  be  resolved  by  replacing  the  ROM  with  a  FPROM 
(Field-Programable  Read  Only  Memory) .  This  replacement  is 
currently  under  consideration  by  some  of  the  Research  and 
Development  agencies . 

In  addition  to  the  supply  system,  the  other  alterna¬ 
tive  methods  of  distributing  ROM  are  the  same  as  discussed 
for  SCP  distributed  on  magnetic  tape  through  the  mail  or  by 
hand  carrying.  As  noted,  neither  of  these  alternatives  are 
an  acceptable  solution  to  the  problem. 

The  final  method  to  distribute  software  changes  is 
through  the  Automatic  Digital  Network  (AUTODIN) .  AUTODIN  is 
a  general  purpose  Department  of  Defense  communication  system 
designed  to  transmit  both  narrative  and  data  pattern  traffic 
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to  subscribers  throughout  the  world.  Under  the  management  of 
the  Defense  Communication  Agency  (DCA) ,  the  network  is  com¬ 
prised  of  a  series  of  AUTODIN  Switching  Centers  (ASC)  located 
in  CONUS,  and  OCONUS  Theaters.  Both  narrative  and  data  pattern 
traffic  is  automatically  routed  through  the  ASC  to  Telecommuni¬ 
cations  Centers  (TCC)  which  provide  over-the-counter  message 
service  to  customers  located  on  a  military  installation  and/or 
in  a  geographical  area. 

The  TCC  are  configured  with  a  number  of  different 
types  of  terminal  equipment  to  meet  the  needs  of  the  individ¬ 
ual  customers  serviced.  The  majority  of  TCC  providing  service 
to  ADP  customers  have  the  capability  to  transmit  and  receive 
data  pattern  traffic  using  either  magnetic  tape  or  eighty 
column  cards.  Since  the  use  of  cards  is  cumbersome  and  readily 
susceptible  to  errors ,  virtually  all  TCC  that  support  Data 
Processing  Installations  (DPI)  have  tape  capability,  or  are  in 
the  process  of  being  upgraded  to  provide  for  it. 

In  addition  to  TCC,  Standard  Remote  Terminals  (SRT) , 
are  being  installed  at  various  locations  to  meet  the  increased 
demand  for  data  transmissions  via  AUTODIN.  The  SRT  are  gener¬ 
ally  linked  either  through  in  Automated  Multi-Media  Exchange 
(AMME)  or  directly  to  the  AUTODIN  network  with  a  configuration 
which  provides  magnetic  tape  capability  to  the  user.  An  SRT 
was  installed  at  the  USACSC  software  support  center  in  1981  to 
afford  immediate  transmission  capability  for  the  distribution 
of  urgently  needed  software  changes.  Having  direct  access  to 


59 


AUTODIN  through  the  SRT  eliminated  the  normal  delays  that  the 
USACSC  had  experienced  when  using  the  over-the-counter  service 
provided  by  the  supporting  TCC .  Also,  the  command  was  better 
able  to  account  for  SCP  transmitted  and  respond  more  rapidly 
to  problems  in  the  field. 

Whether  employing  an  SRT  or  an  installation  TCC,  data 
pattern  transmissions  via  AUTODIN  are  restricted  to  generally 
the  same  format  conventions  as  specified  for  narrative  traffic 
that  is,  the  traffic  must  be  formatted  to  adhere  to  governing 
DCA  regulations  and  circulars  which  specify  message  contex¬ 
tures,  such  as  length  and  addressee  requirements.  In  order 
to  use  AUTODIN  to  distribute  SCP  or  to  transmit  other  data 
traffic,  the  USACSC  developed  a  system  that  would  automati¬ 
cally  format  the  data  to  meet  the  DCA  requirements.  The  sys¬ 
tem  developed  is  the  Standard  Entry /Exit  Service  (SEES) . 

Designed  as  an  interface  between  a  DPI  and  its  ser¬ 
vicing  TCC,  SEES  is  composed  of  a  series  of  utility  programs 
that  give  the  user  the  capability  to  receive  or  send  data  on 
cards  or  magnetic  tape  via  AUTODIN.  The  sender  uses  the  Exit 
portion  of  SEES  to  create  valid  addressee  information  and  to 
separate  the  data  into  the  valid  message  lengths  to  comply 
with  AUTODIN  requirements.  The  receiver  uses  the  Entry  util¬ 
ities  of  SEES  to  separate  the  data  from  the  message  control 
information  required  by  AUTODIN  -  described  as  header  and 
trailer  information  -  and  reconstitutes  the  data  into  a 
machine  loadable  format  for  the  targeted  computer  system. 
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The  SEES  process  has  been  successfully  employed  by  USACSC  to 
transmit  SCP  via  AUTODIN  for  more  than  a  decade. 

The  advantages  of  employing  AUTODIN  to  transmit  soft¬ 
ware  changes  to  users  in  the  field  are  significant.  Foremost, 
an  SCP  can  be  transmitted  to  a  TCC  or  SRT  thousands  of  miles 
away  in  a  matter  of  minutes.  It  can  then  be  rapidly  provided 
to  the  serviced  computer  site  for  loading.  To  verify  the 
velocious  transmission  and  distribution  capability  of  AUTODIN, 
a  test  was  conducted  by  personnel  from  the  USACSC  in  February 
1982. 1  A  test  SCP,  transmitted  from  the  SRT  installed  at  and 
operated  by  the  USACSC  in  Falls  Church,  Virginia,  was  received 
by  the  TCC  at  Ziebruken,  Federal  Republic  of  Germany,  with  a 
total  elapsed  time,  from  time  of  transmission  to  time  of 
receipt,  of  eight  minutes.  It  was  also  received  at  virtually 
the  same  time  -  within  a  minute  or  two  -  at  three  other  TCC 
in  Europe. 

The  above  described  test  also  verified  another  major 
advantage  of  transmitting  software  changes  using  AUTODIN;  the 
automatic  SCP  distribution  capability  built  into  the  system. 

By  transmitting  one  SCP  with  multiple  addressees  -  currently 
SEES  is  limited  to  fifty  addressees  per  transmission  -  AUTODIN 
uses  its  "store  and  forward"  transmission  capability  to  pro¬ 
vide  a  separate  data  message  to  each  addressee.  Therefore, 
the  considerable  drain  on  resources  required  to  reproduce 
numerous  copies  of  an  SCP  and  prepare  it  for  either  mailing 
or  for  hand  carrying  can  be  diverted  to  a  more  compelling 
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software  support  requirement  -  problem  solving. 

To  the  user,  the  most  important  aspect  of  distributing 
SCP  via  AUTODIN  is  the  assurance  that  the  change  received  is 
undamaged  by  mail  and  free  of  utility  copy  errors.  Also,  SEES 
contains  an  extremely  complex  utility  to  guard  against  the 
introduction  of  errors  by  AUTODIN.  The  SEES  utility  is  so 
precise  in  its  determination  that  the  data  received  is  complete 
and  the  object  code  bit  string  is  exactly  as  developed  at  the 
support  center,  that  the  surety  of  having  an  error-free  SCP 
shipment  is  virtually  100  percent.*  While  SEES  is  not  capable 
of  detecting  programming  errors  that  may  have  been  made  at  the 
support  center,  it  assures  that  the  SCP  is  completely  free  of 
transmission  errors  and  ready  for  loading.  If  SEES  does  iden¬ 
tify  a  problem  to  the  intended  user,  a  request  for  a  retrans¬ 
mission  can  be  quickly  sent  to  the  originator. 

Although  the  advantages  of  employing  AUTODIN  for  SCP 
distribution  are  significant,  there  are  some  serious  disad¬ 
vantages.  The  most  severe  problem  is  the  inability  to  receive 
SCP  transmitted  via  AUTODIN  on  any  media  other  than  80  column 
cards  or  on  7-  or  9-track  magnetic  tape.  Software  changes 
developed  for  distribution  on  cassettes  or  cartridges  are  not 

*As  discussed  earlier  in  this  paper,  an  SCP  must  not  be 
altered  in  any  way.  One  data  bit  out  of  sequence  will  render 
the  entire  SCP  useless.  Also,  in  regards  to  the  surety  of 
SEES,  to  the  knowledge  of  the  author  while  assigned  to  USACSC, 
no  SCP  processed  through  SEES  has  contained  any  undetected 
transmission  introduced  error. 
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compatible  with  the  equipment  used  at  the  TCC  or  SRT  and, 
therefore,  cannot  be  transmitted  via  AUTODIN. 

Currently,  the  tactical  units  that  are  the  primary 
beneficiaries  of  the  capability  to  distribute  changes  using 
AUTODIN  are  the  Division  Data  Centers  (DDC)  that  operate  the 
Combat  Service  Support  System  (CS3) .  The  DDC  use  the  van 
mounted  IBM  360  series  computers  with  9-track  magnetic  tape 
drives  which  make  them  compatible  with  the  tapes  produced  by 
the  TCC  and  SRT.  However,  most  of  the  DDC  are  supported  by 
fixed  station  TCC  that  cannot  be  deployed  to  the  tactical 
arena.  Therefore,  if  required  to  tactically  deploy,  the 
DDC's  capability  to  receive  SCP  via  AUTODIN  would  be  extremely 
limited.  There  are  no  tactical  TCC  employed  within  a  division 
capable  of  receiving  data  transmissions  via  tactical  communi¬ 
cations  systems. 

Several  other  problems  experienced  with  the  transmis¬ 
sion  of  software  changes  via  AUTODIN  can  be  attributed  to 
people,  rather  than  technical  deficiencies.  They  range  from 
a  lack  of  understanding  and/or  coordination  between  the  local 
DPI  and  TCC  personnel,  to  problems  with  various  publications 
that  fail  to  provide  adequate  regulatory  and  technical  guid¬ 
ance  to  the  users  in  the  field.  Because  of  these  problems, 

DPI  personnel  have  been  generally  skeptical  about  the  reli¬ 
ability  of  AUTODIN.  Since  the  causes  of  many  of  the  problems 
have  been  identified,  action  is  now  being  actively  pursued 


to  resolve  them.  A  Data  Comm  Work  Group,  composed  of  person¬ 
nel  from  the  USACSC  and  USACC  (U.S.  Army  Communications  Com¬ 
mand)  ,  has  been  founded  to  work  jointly  at  resolving  DPI/TCC 
interface  problems.  Therefore,  the  major  problems  of  AUTODIN 
remain  the  limitation  of  providing  SCP  only  as  80  column  cards 
or  as  7-  and  9-track  magnetic  tape,  and  the  inability  of  divi¬ 
sion  level  TCC  to  receive  data  message  traffic. 

FUTURE  REQUIREMENTS  AND  CAPABILITIES 

Throughout  this  study,  the  present  and  future  require¬ 
ments  for  software  support  of  BAS  have  been  continuously  iden¬ 
tified.  Therefore,  rather  than  reiterate  the  anticipated 
future  requirements  for  each  computer  system,  suffice  it  to 
say  here,  during  the  remainder  of  this  decade,  thousands  of 
computers  will  be  fielded  in  the  tactical  environment  and  each 
will  require  software  support  of  one  degree  or  another.  Pro¬ 
viding  the  required  support  will  be  a  major  challenge  to  all 
PDSS  centers.  Even  with  the  relatively  few  tactical  computer 
systems  that  are  employed  in  the  field  today,  adequate  support 
for  urgent  SCP  can  scarcely  be  provided  with  the  antiquated 
distribution  methods  currently  practiced.  And  as  the  number 
of  BAS  increase  to  meet  future  requirements,  current  practices 
and  procedures  will  prove  woefully  inadequate. 

The  software  support  shortfalls  identified  earlier  in 
this  chapter  are  not  new,  but  with  few  exceptions,  they  have 


64 


gone  either  unnoticed  or  possibly  ignored  by  the  majority  of 
software  support  centers  and  the  Army  ADP  community  as  a  whole 
Few  leaders  in  the  ADP  field  acknowledge  that  as  the  prolif¬ 
eration  of  hardware  is  checked  with  the  development  and  field¬ 
ing  of  standard  hardware,  such  as  the  Military  Computer  Family 
(MCF) ,  software  support  will  move  rapidly  to  the  forefront  as 
the  major  concern  of  system  developers  and  be  a  severe  drain 
on  the  Army's  fiscal  resources.  As  forecast  by  a  Rand  Corpora¬ 
tion  study  conducted  over  a  decade  ago,  "...by  1985  software 

2 

will  consume  95%  of  our  defense  computer  system  dollars." 

In  general,  the  ADP  system  developers  in  the  Army 
have  been  reluctant  to  expend  the  resources  necessary  to 
improve  the  SCP  distribution  capability  to  meet  future  soft¬ 
ware  support  requirements.  A  preoccupation  with  software 
development  rather  than  software  support  throughout  the  years 
has  only  recently  been  reversed  with  the  development  of  the 
PDSS  Concept  Plan.  However,  as  previously  noted,  the  plan  is 
lacking  in  definitive  solutions  for  the  rapid  distribution 
of  SCP.  In  fact,  adherence  to  certain  aspects  of  the  plan 
could  delay  the  development  of  more  responsive  SCP  distribu¬ 
tion  capabilities  . 

One  aspect  of  the  PDSS  Concept  Plan  which  has  a  major 
flaw  is  the  requirement  to  establish  a  Contact  Maintenance 
Team  (CMT)  at  direct  support/general  support  (DS/GS)  level  to 
provide  "on-site  support"  and  "install  approved  changes".3 
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If  the  intent  is  to  have  SCP  delivered  via  mail  or  hand  car¬ 
ried  to  the  GS  unit  at  theater  level  for  reproduction  on  a 
computer  test  set  for  further  distribution  to  the  supported 
computer  sites  in  theater,  the  CMT  will  not  provide  any 
improvement  to  current  distribution  practices.  The  time 
delay  problems  associated  with  sending  SCP  through  the  mail 
or  hand  carrying  the  software  changes  to  each  site  will  not 
be  alleviated  by  employing  a  CMT.  Additionally,  the  resources 
necessary  to  reproduce  the  required  number  of  copies  remains 
a  major  unresolved  problem.  If,  however,  the  intent  is  to 
use  the  CMT  for  "on-site  support"  should  a  problem  with  an 
urgent  SCP  load  occur,  then  the  formation  of  the  CMT  is  a 
step  in  the  right  direction. 

Although  the  capability  to  transmit  data  via  tactical 
multichannel  communications  systems  has  existed  and  been 
employed  by  field  commanders  for  a  number  of  years,  little 
consideration  has  been  given  to  developing  the  capability  to 
transmit  SCP  using  the  same  systems.  The  primary  limitations 
have  been  the  poor  quality  of  circuits  provided  by  tactical 
multichannel  systems  and  the  lack  of  data  termination  capabil¬ 
ity  at  the  divisional  TCC  level. 

A  MITRE  Corporation  study  published  in  October  1981 
found  that  when  tactical  multichannel  systems  are  properly 
deployed,  data  can  be  successfully  transmitted  over  the  com¬ 
munications  links.  In  order  to  achieve  quality  communications 
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links,  however,  the  study  recommended  improvements  to  mainte- 

4 

nance,  training,  operations,  and  supervision.  Poor  quality 
circuits  are  unacceptable  for  high-speed  data  messages  and, 
therefore,  the  quality  of  a  tactical  multichannel  communica¬ 
tions  link  must  be  superior  to  successfully  transmit  or  receive 
SCP  when  interfaced  with  AUTODIN.  Unless  the  recommended 
improvements  are  made,  it  is  questionable  whether  SCP  can  be 
successfully  transmitted  via  tactical  systems. 

A  partial  solution  to  the  other  limitation  identified 
above  is  in  the  process  of  being  accomplished.  Data  termina¬ 
tion  capability  is  not  yet  available  at  divisional  TCC;  how¬ 
ever,  an  AUTODIN  interface  capability  will  soon  be  available 
in  the  Decentralized  Automated  Service  Support  System  (DAS 3) . 
The  DAS 3  computers  are  being  provided  to  divisional  and  non- 
divisional  units  as  replacements  for  the  IBM  360s  and  NCR  500 
computer  systems  respectively.  The  AUTODIN  interface  will 
provide  the  DDC  with  the  capability  to  receive  SCP  for  the 
DAS 3  supported  Combat  Service  Support  BFA  directly  from  the 
USACSC  software  support  center.  Also  eliminated  will  be  the 
DPI/TCC  interface  problems  previously  identified. 

An  area  in  which  the  capability  to  transmit  data  mes¬ 
sages  in  a  tactical  environment  has  already  been  improved  is 
the  automatic  message  switching  capability.  As  a  tactical 
interface  with  AUTODIN,  the  Army  has  developed  and  is  in  the 
process  of  fielding  the  AN/TYC-39  Message  Switch  (MS).  The 
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MS  operates  on  the  same  store  and  forward  principle  as  AUTODIN 
and,  therefore,  provides  the  same  automatic  distribution  capa¬ 
bility  for  multiple  addressed  SCP  in  the  tactical  arena  as  in 
the  fixed  station  environment.  With  the  exception  of  the  capa¬ 
bility  being  provided  to  the  DAS3  computers,  the  major  limita¬ 
tion  to  the  use  of  the  MS  for  SCP  distribution  is  the  lack  of 
data  termination  equipment  currently  available  at  division 
level . 

✓ 

Other  study  efforts  to  improve  the  capability  to  trans¬ 
mit  data  as  input/output  (I/O)  from  tactical  computer  systems 
has  involved  the  use  of  Army  tactical  FM  radios .  One  such 
study  placed  emphasis  on  improvement  considerations  for  the 
AN/VRC-12  and  the  AN/PRC-77  radio  sets.5  The  Maneuver  Control 
System  (MCS)  is  an  example  of  how  those  tactical  FM  radios 
can  be  successfully  employed  to  transmit  data  through  a  TCS 
and  TCT  interface.  To  date,  no  attempt  has  been  made  to  trans¬ 
mit  an  SCP  employing  FM  communications . 

While  there  has  been  considerable  thought  and  effort 
expended  to  develop  the  capability  to  rapidly  distribute  SCP 
for  batch  processed  business-type  systems  operated  on  the 
DAS 3 ,  a  comparable  effort  has  not  been  given  to  developing 
the  capability  for  real-time  command  and  control  systems. 
Unfortunately,  it  is  the  real-time  BAS  systems  that  the  field 
commanders  will  rely  on  during  time  of  war.  It  is  on  the 
real-time  systems,  therefore,  where  the  effort  should  be 
placed . 
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CHAPTER  V 


CONCLUSIONS  AND  RECOMMENDATIONS 

GENERAL 

From  the  outset,  the  designed  purpose  of  this  study 
"...is  to  investigate  the  feasibility  of  developing  a  stand¬ 
ard  means  for  the  rapid  distribution  of  urgent  software  changes 
to  all  divisional  and  non-divisional  computer  systems  in  tac¬ 
tical  units  located  in  OCONUS  Theaters.  The  development  and 
subsequent  adherence  to  standard  procedures  should  ultimately 
minimize  the  degradation  of  command  and  control  due  to  soft¬ 
ware  failures."  Unfortunately,  even  the  need  for  a  standard 
means  for  distributing  SCP  is  doubtful  in  the  minds  of  some 
members  of  the  Army  ADP  community. 

While  conducting  the  research  for  this  study,  the 
author  came  in  contact  with  some  Army  ADP  personnel  who 
expressed  misgivings  about  the  requirement  to  rapidly  distrib¬ 
ute  software  changes  to  the  field.  The  sentiment  was  that 
software  problems  can  be  averted  by  thoroughly  testing  new 
software  versions  prior  to  fielding.  These  same  people  did, 
however,  admit  that  the  present  mailing  and  hand  carrying 
procedures  employed  during  peacetime  would  be  inadequate 
during  war.  Queries  about  plans  to  meet  wartime  contingencies 
invariably  met  with  a  negative  response.  Therefore,  if  read¬ 
ers  of  this  study  are  skeptical  about  the  need  to  have  a 
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standard  Army-wide  SCP  distribution  procedure,  they  need  only 
to  ask,  "What  are  the  alternatives?" 

Undoubtedly,  many  administrative  and  technical  prob¬ 
lems  will  be  experienced  while  establishing  a  standard  pro¬ 
cedure.  Administratively,  plans  will  have  to  be  developed  by 
the  PDSS  centers  to  provide  the  resources  necessary  to  employ 
the  means  devised  to  meet  the  software  support  requirements. 
Technically,  the  means  to  provide  the  capability  to  rapidly 
distribute  SCP  must  be  developed.  However,  there  is  little 
doubt  that  the  development  of  a  standard  means  for  the  rapid 
distribution  of  urgent  software  changes  to  all  divisional  and 
non-divisional  computer  systems  in  tactical  units  located  in 
OCONUS  Theaters  is  feasible. 

The  study  covered  the  aspects  of  reaffirming  the  need 
and  examined  the  present  capability  to  rapidly  provide  SCP  to 
the  field.  Simple  solutions  were  not  sought  and  none  can  be 
provided.  However,  the  author  drew  several  conclusions  from 
the  research  which  provided  the  basis  to  present  recommenda¬ 
tions  for  the  resolution  of  the  problem. 

CONCLUSIONS 

1.  The  dynamic  nature  of  software  dictates  that 
regardless  of  the  amount  of  testing,  problems  will  arise  or 
requirements  will  change  that  necessitate  urgent  software 
changes .  The  current  trend  to  move  to  exceedingly  more  com¬ 
plex  software  increases  the  probability  of  software  failures. 
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2.  The  increasing  reliance  on  computers  for  command 
and  control  by  field  commanders  requires  that  software  changes 
be  provided  quickly  lest  a  serious  degradation  in  the  decision 
making  capability  of  the  commander  be  experienced. 

3.  While  the  PDSS  Concept  Plan  is  a  movement  in  the 
right  direction,  it  is  deficient  in  its  failure  to  adequately 
address  the  SCP  distribution  requirements  of  software  support. 

4.  The  SCP  Questionnaire  verified  that  with  no  stan¬ 
dard  procedure  available,  software  support  throughout  the 
Army  is  accomplished  with  a  "shotgun"  approach;  that  is,  PDSS 
centers  use  the  distribution  method  that  happens  to  suit  the 
project  that  is  "hot"  at  the  time . 

5.  There  is  an  over-reliance  on  distributing  software 
changes  by  mailing  or  hand  carrying.  Neither  alternative 
would  be  an  acceptable  solution  during  time  of  war. 

6.  AUTODIN,  with  its  current  capabilities,  cannot  be 
used  to  electronically  distribute  SCP  without  extensive  up¬ 
grading  to  provide  the  proper  media  interface  capability. 
However,  the  use  of  SEES  with  AUTODIN  transmissions  does  prove 
the  capability  and  reliability  of  transmitting  SCP  electronic¬ 
ally. 

7.  There  is  a  major  problem  with  the  use  of  ROM  in 
certain  wartime  systems  if  rapid  programming  changes  must  be 
made. 

8.  The  capability  to  provide  urgent  SCP  rapidly  to 
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divisional  and  non-divisional  BAS  while  tactically  deployed 
during  time  of  war  does  not  exist,  nor  does  it  appear  that 
the  capability  will  exist  in  the  near  future  unless  an  exten¬ 
sive  effort  to  resolve  the  problems  identified  in  this  study 
is  undertaken  by  the  entire  ADP  community. 

RECOMMENDATIONS 

The  conclusions  drawn  from  the  research  have  led  to 
several  recommendations  on  how  to  accomplish  the  development 
of  a  standard  software  distribution  procedure  for  adoption 
Army -wide. 

1.  The  capability  of  AUTODIN  must  be  expanded  to 
provide  the  electronic  means  to  distribute  SCPs  to  all  BAS 
in  the  field.  Key  to  this  requirement  is  providing  terminal 
equipment  and/or  ADPE  interfaces  -  similar  to  that  currently 
being  accomplished  for  the  DAS 3  -  which  allow  receipt  of  the 
SCP  on  BAS  specific  medium.  This  expanded  capability  would 
not  be  limited  to  SCP  distribution  only,  but  would  also  facili¬ 
tate  the  rapid  movement  of  data  throughout  all  echelons  of  the 
Army  regardless  of  the  geographical  location  of  the  unit. 

2.  If  it  is  not  feasible  to  expand  AUTODIN  to  meet 
the  growing  data  transmission  requirements,  a  new  world-wide 
network  comparable  to  AUTODIN  must  be  established  to  provide 
a  means  to  rapidly  distribute  data.  The  network  must  operate 
employing  a  "store  and  forward"  capability,  rather  than  the 


more  restrictive  "packet  switching"  design  evisioned  for  the 
now  cancelled  AUTODIN  II  system.  (Packet  switching  provides 
only  a  single  addressee  capability  and,  therefore,  it  would 
not  be  able  to  distribute  data  to  multiple  sites  with  a  single 
transmission.)  As  with  AUTODIN,  the  new  network  would  be  used 
for  all  data  traffic,  not  solely  restricted  to  SCP  transmis¬ 
sions.  Also  required  would  be  the  capability  to  terminate 
transmissions  at  division  level  with  multi-media  capability, 
or  possibly,  a  direct  connection  to  support  computers  located 
at  DS  units  in  the  division  for  further  distribution  to  the 
battalions  and/or  separate  companies  if  required. 

3.  A  task  force  similar  to  the  one  established  for 
the  PDSS  study  should  be  formed  to  develop  a  viable  solution 
to  the  problem.  However,  rather  than  restrict  the  membership 
to  the  Army  ADP  community,  the  task  force  should  be  composed 
of  members  from  the  communications  community  as  well.  Ulti¬ 
mately,  the  goal  should  be  to  have  DOD-wide  involvement. 

4.  To  improve  the  quality  of  the  tactical  multi¬ 
channel  communications  systems,  the  MITRE  Corporation  study 
recommendations  must  be  vigorously  pursued  by  the  communica¬ 
tions  community.  Regardless  of  the  means  chosen,  the  quality 
of  the  communications  links  in  the  tactical  arena  is  the  key 
to  having  the  capability  to  electronically  transmit  the  SCP 
to  tactical  BAS  computers . 

5.  An  effort  must  be  made  to  replace  the  ROM  used 
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in  a  variety  of  BAS  with  FPROM.  Only  then  will  the  capability 
to  provide  immediate  programming  changes  to  those  systems  be 
realized.  Changes  to  those  systems  could  then  be  transmitted 
electrically  from  the  PDSS  center  in  CONUS  to  a  support  center 
in  the  OCONUS  Theater. 

Although  this  study  suggests  that  a  standard  distribu¬ 
tion  procedure  for  adoption  Army  wide  is  feasible,  only  empha¬ 
sis  from  the  highest  levels  of  the  Army  can  result  in  the 
dedication  of  the  resources  necessary  to  develop  the  capabil¬ 
ity.  Without  that  emphasis,  the  current  antiquated  practices 
of  mailing  or  hand  carrying  software  changes  to  the  tactical 
BAS  will  continue  to  be  the  standard  procedures  for  the  PDSS 
centers.  It  can  then  be  guaranteed  that  a  catastrophic  com¬ 
puter  failure  will  occur  in  the  early  days  of  the  next  war, 
and  we  will  be  helpless  to  quickly  resolve  it. 
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Software  Change  Package  Questionnaire 


1.  The  following  questions  focus  on  how  your  organization 
currently  produces  and  distributes  software  changes  for  the 
computer  systems  supported  by  you.  Information  in  addition 
to  that  yielded  by  the  questions  and  responses  provided  is 
welcome  and  solicited.  The  questionnaire  was  designed  to  be 
applicable  to  the  broad  spectrum  of  software  development  and 
design  centers,  and  not  to  any  one  particular  agency. 

a.  What  method  of  distribution  for  software  changes  is 
used  by  your  organization? 

Mail  XXXXXX 

Military  courier  x 

Commercial  overnight  service  _ 

AUTODIN  XX 

Other  XXX X  (Please  explain) 

Note:  If  more  than  one  method  is  used,  the  above  answers 

can  be  expressed  as  a  percentage. 

b.  If  mailed,  what  is  the  average  time  it  takes  to  get 
to  the  addressee? 

CONUS  Addressee:  3-5  days  X 

6-14  days  XXXX 

15-30  days  _ 

30-90  days  _ 

More  than  90  days  _ 

OCONUS  Addressee:  3-5  days  X 

6-14  days  X 

15-30  days  XXXX 

30-90  days  _ 

More  than  90  days  _ 
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c.  If  sent  via  AUTODIN,  what  is  the  average  time  it  takes 
for  the  addressee  to  receive  it? 

Same  day  X 

1-3  days  X 

4  or  more  days  _ 

d.  How  often  do  you  send  changes  to  the  field? 

Monthly  i 

Semi-annually  1 . 2  f 1 f  ? 

Annually  1 , 10 

Note:  In  answering  the  above  question,  put  the  average 

number  of  changes  sent  per  system;  i.e.,  if  twice 
a  month,  enter  a  "2"  after  monthly. 

e.  Including  all  systems  supported  by  you,  what  is  the 
average  number  of  changes  sent  per  month?  1,1 

f .  Are  the  problems  which  are  being  corrected  by  the 
software  change  considered  to  be: 

Emergency  (i.e.  the  system  has  quit  functioning)  XX 

Urgent  (i.e.  the  system  is  functioning,  but  serious 
problems  exist)  XXXX 

Routine  (i.e.  changes  are  in  response  to  a  routine 
ECP)  XXXXXXX 

g.  What  is  the  organizational  level  your  changes  are 
sent  to: 


Installation  x 

Theater  _ 

Corps  X 
Division  XXXXX 
Battalion  XXXXX 
Company  XX 

Note:  If  sent  to  more  than  one  organizational  level, 
the  response  should  be  expressed  as  a  percentage. 


78 


h.  Are  the  systems  supported  by  your  organization  operated 
by  trained  ADP  operators  or  the  functional  users? 

ADP  operators  XX 

Functional  users  XXXXXXXX 

i.  Are  software  maintenance  personnel  available  to  make 
software  changes  on  site? 

Yes  XX 

No  XXXXXX 

j .  If  you  answered  no  to  the  above  question,  who  applies 
the  software  changes  provided  by  you? 

Operator  XX 

Contractor  XX 

Other  XX  (Please  explain) 

k.  What  medium  is  used  to  send  changes  to  the  field? 

Magnetic  tape  XXXX 

Floppy  disc  _ 

Cassette  XXX 

Cards  _ 

l.  How  are  multiple  copies  of  the  changes  produced  for 
distribution  to  the  users? 

Multiple  copies  locally  reproduced  XXXXX  (Adv  number/ 
system  _ ) 

One  copy  sent  via  AUTODIN  X  (i.e.  distribution 
accomplished  with  AUTODIN) 

Other  XX  (Please  explain) 

m.  Is  any  reproduction  of  changes  accomplished  at  sites 
other  than  the  CONUS  based  development  and  design  centers? 

No  XXX 

Yes  XXXX  (Please  explain) 


n.  Are  the  responses  provided  for  questions  a  through  m 
above  based  on: 

Developmental  system (s)  X 

Fielded  system(s)  XXXXXXX 

o.  If  the  question  above  is  answered  with  Developmental 
system(s)/  has  a  plan  for  the  distribution  of  software  changes 
been  developed  for  the  fully  fielded  system? 

Yes  X 

No  _ 

p.  If  yes  is  the  response  to  the  above  question,  explain 

as  concisely  as  possible  how  the  plan  differs  from  the  responses 
provided  for  all  of  the  above  questions.  None 


2.  The  following  questions  focus  on  why  your  organization 
uses  the  procedures  as  outlined  in  paragraph  1  above. 

a.  Are  the  procedures  used  because  they  provide: 

Quick  delivery  XXXXX 

Error  free  transmittal  XXXXX 

Configuration  Management  (CM)  control  XXXXXXXX 
Surety  X 

Other  XXX  (Please  explain) 

b.  What  are  the  shortcomings  or  inadequacies  of  the  system 
presently  used? 

c.  In  your  estimation,  how  can  the  system  be  improved? 


3.  Request  that  the  name  and  telephone  number  of  the  individ¬ 
ual  responding  to  this  questionnaire  be  provided  below.  For 
any  questions  concerning  this  questionnaire,  contact  MAJ  W.  E. 
Francis  at  AUTOVON  552-2748. 
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LIST  OF  ABBREVIATIONS 
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LIST  OF  ABBREVIATIONS 


ADP:  Automatic  Data  Processing 

ADPE :  Automatic  Data  Processing  Equipment 

ADPS:  Automatic  Data  Processing  System 

ADSAF:  Automatic  Data  Systems  within  the  Army  in  the  Field 

ASC:  AUTODIN  Switching  Center 

AUTODIN:  Automatic  Digital  Network 

BAS:  Battlefield  Automated  Systems 

BASOPS:  Base  Operations  Informations  Systems 

BFA:  Battlefield  Functional  Area 

CCIS70:  Command  Control  Information  Systems  1970 

CD:  Combat  Developer 

CECOM:  U . S .  Army  Communications-Electronics  Command 

CM:  Configuration  Management 

CMT:  Contact  Maintenance  Team 

CONARC:  Continental  Army  Command 
CONUS:  Continental  United  States 

CORADCOM:  U.S.  Army  Communications  Research  and  Development 
Command 

CPU:  Central  Processing  Unit 
CS3:  Combat  Service  Support  System 

DAS 3 :  Decentralized  Automated  Service  Support  System 
DC A:  Defense  Communications  Agency 

DDC:  Division  Data  Center 
DOD:  Department  of  Defense 
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